In a multi-channel blockchain-based IoT system, the combination of blockchain technology and DID ensures secured and trusted data sharing between devices. The system leverages the decentralized nature of blockchain to store and verify data, while DID serve as a unique and tamper-proof identity for each IoT device. This setup guarantees that data exchanges between devices are secure and protected from external interference.
In the context of IoT, blockchain multi-channel architecture allows different categories of IoT devices to be assigned to distinct blockchain channels, each dedicated to a specific type of data or operation. This separation ensures that data privacy and integrity are maintained, while cross-channel data sharing are securely facilitated through well-defined protocols.
5.1. System Initialization
This section describes the system initialization process, including four key steps. First, the system generates the necessary homomorphic encryption parameters, defines the polynomial ring
R and the modulo chain
Q to support CKKS homomorphic encryption computation, and stores them publicly on the blockchain to ensure transparency. Next, the IoT device generates DID key pairs via the Elliptic Curve Digital Signature Algorithm (ECDSA) [
27] and ensures that the private key is kept only by itself to avoid identity disclosure. Subsequently, the IoT device submits a registration request containing identity attributes and its signature to the authority center, which verifies the validity of the signature, generates a unique DID for it and stores it in the blockchain to achieve verifiable decentralized identity management. Finally, to guarantee the security of trusted computing channels, the system generates CKKS homomorphic encryption keys for each channel, including public-private key pairs and evaluation keys, to support subsequent cryptographic computation.
This initialization process ensures the security of the IoT device’s identity, the feasibility of data encryption computation, and the transparency and verifiability of the overall scheme.
Step 1: Generate system parameters
: Define the polynomial ring as , where n is a power of two to ensure efficient transform operations. Choose a precision scaling factor to control the trade-off between precision and noise growth in encrypted computations. Select an integer base and an initial modulus , which together define a modulus chain where each modulus level is given by
This modulus chain allows ciphertext modulus reduction, which is a key feature in CKKS to maintain numerical stability and control noise growth during homomorphic operations. The system parameters, including n, , p, , and the modulus chain Q, are made public and storing it on the blockchain to assure transparency and reproducibility in encrypted computations.
Step 2: Generate key pairs for DID
: The DID registration process is shown in Algorithm 1. IoT devices can autonomously generate DID key pairs. After generating the DID key pair, each IoT device needs to register the DID on the blockchain.
The IoT device generates DID key pairs by selecting Elliptic Curve Digital Signature Algorithm (ECDSA) for identity authentication and recognition [
27]. ECDSA was chosen because it balances security and efficiency and is suitable for resource-constrained environments typical of IoT devices.
Select elliptic curve parameters
, where
p is a prime number in a finite field,
is the coefficients of the elliptic curve equation,
h is cofactor,
n is prime order of
G and
G is base point. The DID key generation process is shown in Equation (
1). The private key
is randomly selected from the set
, ensuring that it is a valid scalar for point multiplication on the elliptic curve. The corresponding public key
is then calculated as
, which is the result of scalar multiplication of the base point
G by the private key
. The calculation process is as follows:
The private key is generated and stored by the IoT device itself, and is not stored by the AC. The AC is responsible for verifying the legitimacy of the identity information of the IoT device. The autonomous and controllable DID identity can avoid the leakage of private identity information.
Algorithm 1 IoT device DID Identity Registration |
Input: IoT devices with attribute set Output: Registered and verifiable
- 1:
Step 1: Generate Key Pairs - 2:
- 3:
Step 2: Send Registration Request - 4:
IoT device prepares registration request: - 5:
- 6:
IoT device sends to . - 7:
Step 3: Identity Verification - 8:
extracts information from . - 9:
verifies the signature: - 10:
- 11:
if Verification is invalid then - 12:
Reject registration request and terminate. - 13:
end if - 14:
Step 4: Generate DID Document and Attribute List - 15:
Generate unique DID for the IoT device: - 16:
- 17:
Construct DID Document and Store into the attribute list. - 18:
Step 5: Register DID on Blockchain - 19:
Call blockchain registration function: - 20:
Blockchain_Register - 21:
if Registration successful then - 22:
Return confirmation and to IoT device. - 23:
else - 24:
Return registration failure and terminate. - 25:
end if
|
Step 3: IoT device authentication
: The AC checks the attribute information
of the IoT device and verifies the correctness of the attribute source by verifying the signature
with the DID public key
. The DID signature process is shown in Equation (
2), and the DID signature verification process is shown in Equation (
3).
During the signing process, the attribute information is first hashed to obtain a fixed-length digest. A random scalar
k is then chosen, and the corresponding elliptic curve point is computed to derive the signature component
r. The final signature component
is computed using the private key
and the hashed attribute. The signing process is as follows:
For verification, the recipient checks the validity of the signature by ensuring that both
r and
s fall within the acceptable range. The verifier then computes an intermediate value
w and uses it to derive two scalars
and
, which are used to reconstruct a point on the elliptic curve. If the computed x-coordinate matches
r, the signature is deemed valid, confirming the authenticity of the attribute information. The signature verification process is as follows:
5.2. In-Channel Data Sharing
This process describes secure data sharing between different IoT devices within a blockchain channel. Data sharing within the channel is achieved through hybrid encryption, with symmetric encryption using AES and asymmetric public key encryption using RSA [
28]. The entities involved include the data owner (DO) and the data requester (DR). The process consists of four main steps: data encryption and upload, data request, access control, and data acquisition.
Figure 2 shows the data sharing process between IoT devices within the channel.
Step 1: Data encryption and upload
The DO encrypts the
using AES encryption in Cipher Block Chaining (CBC) mode:
where
is a randomly generated 128-bit initialization vector.
The AES encryption process follows:
where
is symmetric encryption key, ⊕ denotes bitwise XOR operation, and
represents the ciphertext block for the
i-th plaintext block
.
The DO then uploads
to IPFS and receives the corresponding storage address:
Step 2: Data request
DR submits data request to the blockchain PN with a digital signature for verification, where is a digital signature generated with DR’s .
The PN verifies the request with . Only if verification succeeds, the request proceeds.
Step 3: Access control
The DO encrypts the symmetric key
and the storage address using the PN’s public key:
where
is the public key of the PN.
DO formulates an access control policy and submits it along with to the PN.
The PN retrieves DR’s attribute list from the authority center and evaluates the access control policy:
If the policy is satisfied (
), the PN decrypts
and re-encrypts it for the DR using
:
The encrypted information is then sent to the DR.
Step 4: Data acquisition
The DR decrypts
using its private key:
The DR retrieves the encrypted data from IPFS:
The AES decryption in CBC mode follows:
Finally, the DR obtains the shared data . Thus, DR can securely access sharing data as well as keep the integrity and confidentiality of the process intact.
5.3. Data Privacy Computation Between Cross-Channel IoT Devices
Figure 3 shows the process of privacy calculation for different channels. In cross-channel IoT device data sharing, we adopt the fully homomorphic encryption scheme CKKS to achieve privacy protected cross-channel data sharing [
29,
30].
is the CKKS PN of channel 1, and
is the CKKS PN of channel 2. Assuming that
needs
’s data to complete some business,
and
can perform privacy calculations through CC.
CKKS supports floating-point data, making it more suitable for IoT scenarios. Specific application scenarios include hospitals and insurance companies using CKKS to predict or calculate patient premiums while protecting sensitive raw data. Insurance companies request patient medical data from hospitals via cross-domain data requests. Hospitals encrypt medical data (e.g., medical expenses) using the insurance company’s CKKS public key. Insurance companies can encrypt premium calculation model data (e.g., encrypted weighting data) and use CC to calculate patient premiums. Finally, insurance companies decrypt the calculation results.
The specific cross-channel IoT devices trusted data privacy calculation process is as follows:
Step 1: Generate and distribute CKKS keys
CKKS.KeyGen. For a given security parameter , the algorithm initializes multiple parameters. Select modulus M as a power-of-two integer satisfying security requirements, define Hamming weight parameter h to control private key sparsity, set a large integer P as the extended modulus for relinearization, and determine Gaussian noise standard deviation to ensure scheme security.
Core sampling operations consist of sample the
s from the Hamming weight distribution
, uniformly sample random polynomial
a from the ring
, and generate noise polynomial
e via discrete Gaussian distribution
. Set channel 1’s
as
and channel 1’s
as
In the process of generating the evaluation key for our scheme, we begin by sampling a random polynomial
from the ring
, denoted as
. Simultaneously, an error term
is sampled from a discrete Gaussian distribution with variance
, i.e.,
. The channel 1’s evaluation key is then formed as a pair
, where the component
is computed as follows:
In this equation, the term reflects the standard encryption structure, adds necessary noise for security, and the additional term ensures correctness during homomorphic multiplication.
As a result, the channel 1’s evaluation key is given by the following:
This evaluation key enables homomorphic multiplication operations and ensures that decryption remains correct while maintaining both key security and manageable noise growth.
Step 2: Channel 1 sends homomorphic encryption request
Assuming that the IoT device in channel 1 needs some data from channel 2 to complete certain business, IoT device needs to initiate a cross-channel data request to the , and then the will initiate a data request to CC and provide DID information of all parties involved in the cross-channel data sharing process. This DID information is used to verify the authenticity of the data provider’s identity.
Step 3: Encode the original data and encrypt it
Both parties involved in privacy computing need to use the CKKS public key of the channel where the requester is located to encode and encrypt the data. We first define the following mappings:
The definition of canonical embedding mapping
is shown in Equation (
12).
where
represents the N primitive roots of the polynomial
.
The definition of
as the subring of
is shown in Equation (
11).
The definition of natural projection mapping
is shown in Equation (
12).
The encoding function is as follows:
This mathematical transformation describes a sequence of mappings from a complex vector space through intermediate algebraic structures to a ring .
1. The first mapping transforms from into the space .
2. The next step involves rounding, denoted by , which projects elements from into .
3. The final transformation maps the result back into the ring .
The notation represents an input vector, which undergoes this series of transformations, ensuring that the final result is within the target ring .
The encoding process is as follows:
CKKS.Encode. The encoding phase transforms a -dimensional complex vector into a ring element compatible with homomorphic operations. Initially, the map projects z into the space . A precision-preserving scaling operation is then applied by multiplying the projected result with a scaling factor , which amplifies the fractional components of z to minimize information loss during discretization. Subsequently, a coordinate-wise rounding function rounds the scaled value, where denotes the ring’s canonical coefficient embedding space.
The encoding process can be expressed as
The encryption process is as follows:
. Let
and
. Then, we generate the following ciphertext:
Step 4: Perform homomorphic encryption computation
CC needs to verify and match the identity information of the data provider before performing CKKS operations to assure the legitimacy of data provider’s identity. Subsequently, legitimate participants will undergo privacy calculations and the results will be returned to the requester of the privacy calculations.
The basic operations of homomorphic encryption include addition and multiplication, and the calculation process is as follows:
CKKS.Add
. For
, Homomorphic addition of two ciphertext messages to obtain ciphertext
:
. The evaluation key
is required to perform the CKKS multiplication operation, we assume two ciphertext data
and
. For
,
, we can get
We obtain the ciphertext
after homomorphic multiplication:
The specific content of multiplication ciphertext
is as follows:
Step 5: Decrypt encrypted data and decode it
The CKKS PN of the privacy computation requester from channel 1 decrypts and decodes the homomorphic encryption operation result.
The data decryption process is as follows:
. For
, the CKKS PN of channel 1 decrypts ciphertext
c with
to obtain polynomial plaintext information. The calculation process is shown in Equation (
15).
The decoding process is as follows:
CKKS.Decode
. For a given plaintext polynomial
, it is necessary to first use
for canonical embedding to obtain
, then remove the scaling factor with
and finally use
for projection mapping to obtain the message vector
z as follows:
5.4. Access Permission Management
This section will introduce the specific process of managing access permissions for IoT devices. Managing access permissions for IoT devices includes IoT devices permission update and revocation. Our solution is based on DID to implement access control for IoT devices. The DID documents registered on the blockchain do not involve permission information. Our scheme achieves access permission management for IoT devices through the DID status list and attribute list managed by the AC.
5.4.1. Permission Update
When the role or access scope of an IoT device needs to be changed, permission updates will be implemented through the following steps.
Step 1: Trigger permission update request
The IoT device submits a permission update request to the AC with . The request information includes DID information, new permission attribute information , and signature information with a timestamp .
Step 2: Verification and execution
The AC verifies the validity of the request signature and the correctness of the new permission attributes . After verification, the AC updates the attribute list information bound to the DID and generates an update event log.
Step 3: Issue new credentials
After the permissions are updated, the AC synchronizes the key operation hash of the permission update to the blockchain to achieve tamper-proof auditing. At the same time, the AC needs to issue verifiable credentials containing the new permissions to IoT devices to ensure that the devices can prove their latest permissions to resource providers.
5.4.2. Permission Revocation
When the private key of an IoT device is leaked, the device is scrapped, or it needs to be permanently disabled, we need to revoke the permissions of the IoT device. This is achieved through the DID status list in the AC to revoke DID permissions. The permission revocation is implemented through the following steps.
Step 1: Initiate permission revocation
Permission revocation can be initiated autonomously by IoT devices or directly by AC . To facilitate subsequent traceability of permission revocation operations, permission revocation must provide the revocation type (e.g., private key leakage or device scrapping).
Step 2: Update DID status list
When updating the DID status list, the system first checks the current status of the target DID, then marks the target DID status as revoked in the DID status list and deletes the attribute list information bound to the target DID. At the same time, it records the revocation timestamp, administrator information who performed the revocation operation, revocation reason type, and other information. Additionally, the verifiable credentials associated with the DID must be added to the verifiable credential revocation list.
Step 3: Broadcast the results of permission revocation
To prevent IoT devices whose permissions have been revoked from continuing to exchange data with other devices, the AC will broadcast the permission revocation results, and IoT devices will terminate data exchange with related devices based on the revocation results.
Our scheme model involves the trusted registration of IoT devices, secure and efficient data sharing among IoT devices within the same domain, and privacy-protected data collaboration processes among IoT devices across domains. It meets the data sharing needs within and across IoT domains, providing a secure, efficient, and trusted data sharing solution for IoT devices.