Decentralized PKI Framework for Data Integrity in Spatial Crowdsourcing Drone Services

D2XChain aims to create a robust, decentralized PKI framework for IoDT, compliant with the X.509 standard. Its design goals are:

• •

  X.509 Compatibility: Ensuring all key PKI functions for IoDT, leveraging blockchain for certificate management.

• •

  Decentralized Trust: Distributing trust to avoid single points of failure and enhancing overall security.

• •

  MITM Attack Mitigation: Implementing stringent security protocols during certificate validation.

• •

  Automation: Utilizing smart contracts and consensus protocols for automated certificate lifecycle management.

• •

  Transparency: Maintaining a transparent and immutable record of certificate histories.

D2XChain integrates blockchain’s architectural and consensus features for IoDT PKI, comprising four main operations:

• •

  Registration: Requesting new certificates for IoDT network entities.

• •

  Validation: Verifying certificate requests to ensure legitimacy and origin.

• •

  Revocation: Invalidating certificates upon security compromise or end of service.

• •

  Verification: Ensuring certificates are valid, unexpired, and unrevoked.

As illustrated in Figure 1, D2XChain’s workflow involves a drone operator initiating a certificate request (CRT), processed by service validators and placed in the pending transactions pool. Validators authenticate transactions and add them to the D2XChain ledger as blocks upon majority approval. Transaction types include CRT initial (certificate issuance) and CRT revoke (certificate annulment). Validators receive rewards for their contribution, while the D2XChain client plugin verifies certificate validity during initial communications.

A ratified transaction becomes a block in the D2XChain ledger upon consensus among service validators. This subsection explores the block structure and the D2XChain ledger’s design principles, emphasizing transparency, immutability, and traceability. Modifications in drone services are swiftly shared and traceable. Each D2XChain block consists of three parts: header, body, and a footer with validator signatures, ensuring secure and transparent record-keeping of drone service changes.

D2XChain blocks are composed of three sections: Header, Body, and Footer, each serving specific functions.

1. 1.

   Header: Integrates unique block identifiers in the D2XChain ledger, with fields for Serial Number, CRT Type, Global State (linking all drone services via hash pointers), and Service-Specific State (maintaining a chronological chain for each drone service).

2. 2.

   Body: Houses service-related data, including Drone Name, Public Key of the Drone Operator, Signature of the Drone Operator, and the Expiry Date of the certificate.

3. 3.

   Footer: Contains the Multi-Signature of service validators, signifying their consensus on the block’s validity.

The multi-signature block, denoted as $\psi_{i}$, is authenticated by $n-1$ service validators, as expressed in Equation 1.

In addition, Figure 2 shows how blocks are arranged inside the D2XChain ledger.

A Drone Operator initiates a certificate request via a CRT initial transaction for their IoDT service. The service validators perform independent sanity checks to authenticate these transactions, ensuring the integrity and legitimacy of the PKI functionalities within D2XChain.

D2XChain employs a series of steps to validate certificate requests by Drone Operators:

1. 1.

   Key Verification: Confirms the match between the Drone Operator’s public key and signature, verifying private key possession.

2. 2.

   Domain Existence Check: Ensures the drone’s public key is not already present in the D2XChain ledger to avoid impersonation.

3. 3.

   Drone Operator Verification: Requires a signed token ‘$t_{0}$‘ placed on the DNS to authenticate the Drone Operator’s legitimacy.

   $$t_{0}\equiv\text{Sign}_{\text{SK}}^{\text{SV}}\left(\text{hash}\left(\text{Tx}+SV_{\text{pk}}\right)\right)$$

   (2)

4. 4.

   Token Placement and Retrieval: Involves the Drone Operator signing and placing the token, and the service validator retrieving and validating it.

   $$\phi_{0}\equiv\text{Sign}_{\text{SK}}^{\text{DO}}(t_{0})$$

   (3)

Successful completion of these checks leads to the validation of the transaction by the service validator. The detailed process is outlined in Algorithm 1 and Figure 3.

D2XChain’s revocation process involves several steps to ensure the authenticity and integrity of the revocation request:

1. 1.

   Key Verification: Checks the alignment of the public key and signature to affirm the Drone Operator’s control over the corresponding private key.

2. 2.

   Drone Existence Check: Confirms the presence of the drone-public key binding in the ledger, which is essential for a revocation request.

3. 3.

   Revoke Request Validation: The Drone Operator generates a token combining the hash of the last transaction for the drone, the current request, and their public key.

   $$t_{1}\equiv\text{hash}\left(Tx_{\text{prev}}^{d}+Tx_{\text{cur}}^{d}+DO_{\text{pk}}\right)$$

   (4)

4. 4.

   Token Placement and Validation: The Drone Operator signs and places the token on the IoDT platform, after which the service validator retrieves and validates it.

   $$\phi_{1}\equiv\text{Sign}_{\text{SK}}^{\text{DO}}(t_{1})$$

   (5)

5. 5.

   Upon successful completion of these steps, the service validator officially endorses the revocation transaction.

The detailed procedure for token generation, placement, and validation is elaborated in Algorithm 2.

All Service Validators in the IoDT framework follow the same protocol to validate revocation requests. A consensus of more than 50% of SVs leads to the appending of a CRT revoke block to the D2XChain ledger, invalidating the certificate within IoDT. These protocols operate within a specialized Ethereum network sandbox tailored for IoDT services.

Certificate verification in D2XChain is managed by a client plugin within the IoDT ecosystem. It checks the validity of certificates against a synchronized storage array in the plugin, aligning with the D2XChain ledger:

• •

  A value of true indicates an active, valid certificate, as seen with ”$Drone_{1}$” in Fig. 4.

• •

  A value of false signifies an unregistered, revoked, or expired certificate, exemplified by ”$Drone_{2}$” in Fig. 4.

This verification mechanism is pivotal for ensuring trusted and secure communication within the IoDT, allowing for the quick identification and invalidation of compromised or outdated certificates.

To enhance integrity in the IoDT framework, an incentive mechanism is introduced for Service Validators. Drone Operators (DOs) pay fees for certificate operations, which are then distributed to SVs as a reward for their validation efforts, promoting system integrity. The specifics of fee allocation are outside this paper’s scope.

D2XChain addresses the risk of centralized trust in conventional PKI by employing a decentralized consortium of SVs. The system’s trust relies on the majority of SVs being honest, reducing the risk associated with single CA compromises. The framework suggests enlisting established root CAs as SVs and adjusting their number for optimal scalability and performance. Details on SV registration and miner certificate issuance are reserved for future studies.

D2XChain’s security is evaluated against the CIA triad model [40], focusing on confidentiality, integrity, and availability in the IoDT ecosystem. Detailed discussions of these security aspects will follow in subsequent subsections.

D2XChain’s security within the IoDT framework focuses on confidentiality, integrity, and availability:

• •

  Confidentiality: Ensured through asymmetric cryptography between SVs and DOs, with the safeguarding of private keys off-chain and transaction validation without knowledge of peers’ actions.

• •

  Integrity: Maintained in SV-DO communication via signed tokens in DNS records and accountable SVs under the consensus mechanism, compatible with both secure and traditional DNS implementations.

• •

  Availability: High availability achieved through a distributed ledger resistant to DoS attacks, bolstered by the geographical dispersion and redundancy of SV nodes.

The cryptographic properties of D2XChain for IoDT were formally verified using Verifpal [41]. The detailed Verifpal model for certificate issuance is given in Figure 5. The tool’s proficiency in analyzing complex protocols and assessing post-compromise scenarios is particularly effective in the IoDT context. Verifpal’s symbolic formal verification approach ensures security in communication sequences between SVs and DOs, with a focus on confidentiality and authentication. The comprehensive model and verification process is depicted in Figure 8.

The primary objective of our framework is to establish a blockchain-based PKI system for the IoDT that is resilient against adversarial threats. In the IoDT context, our adversarial model includes entities such as Drone Operators and Service Validators. These entities may act maliciously, leading to the following potential attacks within our D2XChain framework:

• •

  IoDT Service Request (ISR) Spoofing/MITM Attack

• •

  Malicious Service Validator

• •

  Targeted Attack on IoDT Services

• •

  Sybil Attack in IoDT Network

Table I outlines the nature of these attacks, the category of adversaries they fall under, and how D2XChain mitigates such threats.

• •

  ISR Spoofing/MITM Attack: D2XChain counters service request spoofing and MITM attacks. Service Validators verify proof of ownership from the IoDT service registry, with the network’s distributed nature reducing the risk of successful DNS poisoning affecting all Validators.

• •

  Malicious Service Validator: To address dishonest actions by Service Validators, D2XChain employs smart contracts enforcing due diligence. The consensus mechanism ensures only certificates validated by a majority are accepted, and persistent dishonesty leads to removal from the network. Further research will focus on distinguishing between legitimate and malicious validators.

• •

  Victim Targeted Attack: In cases where Service Validators neglect ISR requests for specific services or operators, D2XChain escalates these requests and ensures other Validators process them. A log of inactivity and non-participation helps identify and potentially penalize negligent Validators.

  Adversary Category	Attacks	Description	Mitigation
  Drone Operator	ISR Spoofing/MITM	Pretending to be a legitimate IoDT service to hijack communications.	Rigorous validation checks for ISR initiation and revocation.
  Service Validator	Malicious Service Validator	Validators who endorse unauthorized transactions.	Consensus requirement of over 50% of Service Validators. Monitoring of Validator activities.
  Service Validator	Victim Targeted Attack	Overlooking ISR requests from a specific IoDT service.	Escalating transaction priority over time. Logging Validator inactivity.
  Service Validator	Sybil Attack in IoDT	Introducing numerous deceitful Service Validators to dominate the network.	A permissioned network of trusted Service Validators. Decentralized consensus.

• •

  Sybil Attack: D2XChain employs specific strategies to mitigate the risk of Sybil attacks within the IoDT network:

  • –

    Permissioned Network: D2XChain operates as a permissioned network with authenticated Service Validators, each granted a certificate by D2XChain to participate actively.

  • –

    Decentralized Trust: Trust in D2XChain is established through decentralized consensus among Validators, supported by an autonomous validation protocol, rather than reliance on a single entity.

  • –

    Resilience Against 51% Collusion: D2XChain’s private and trusted Validator ensemble makes it robust against 51% collusion attacks, a common vulnerability in blockchain systems.

  • –

    Incentivization for Integrity: The network incentivizes honest behavior among Service Validators, promoting overall integrity and reducing the likelihood of fraudulent activities.

An evaluation of D2XChain against the design goals established in Section III-A yields the following:

• •

  Compatibility with Existing Standards: D2XChain aligns with the operational principles of traditional PKI systems, ensuring compatibility with existing IoDT infrastructures and standards.

• •

  Decentralized Trust: The framework decentralizes trust by distributing it among multiple Service Validators rather than relying on a single Trusted Third Party, crucial for IoDT’s distributed nature.

• •

  Mitigation of MITM Attacks: D2XChain’s validation protocols robustly address MITM threats, including comprehensive checks against DNS records to prevent unauthorized access.

• •

  Automation: The system automates certificate lifecycle management, processing Service Requests as blockchain transactions with minimal human intervention.

• •

  Transparency: Leveraging blockchain technology, D2XChain offers transparency in the auditing of IoDT service certificates, with an immutable ledger enhancing trust in the system.

D2XChain’s implementation and performance within the IoDT are assessed as follows: