🤖 AI

A Relay-Chain-Powered Ciphertext-Policy Attribute-Based Encryption in Intelligent Transportation Systems

This paper proposes a relay-chain-powered architecture that integrates context-aware smart contracts with a modified Ciphertext-Policy Attribute-Based Encryption (CP-ABE) scheme to enable secure, low-latency, and scalable data sharing across heterogeneous Intelligent Transportation Systems.

Original authors: Aparna Singh, Geetanjali Rathee, Chaker Abdelaziz Kerrache, Mohamed Chahine Ghanem

Published 2026-02-23

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Aparna Singh, Geetanjali Rathee, Chaker Abdelaziz Kerrache, Mohamed Chahine Ghanem

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a massive, bustling city where millions of self-driving cars are constantly talking to each other. They share everything: "There's a pothole ahead," "I'm speeding up," or "Accident at the intersection!" This is the Intelligent Transportation System (ITS).

The problem? If everyone shouts everything to everyone, it's chaotic. Worse, if a hacker jumps in, they could lie about an accident to cause a pile-up, or steal private data about where you live. Also, storing all this data in one giant cloud is slow and risky; if that cloud goes down, the whole city stops.

This paper proposes a new way to manage this traffic of information. Think of it as building a super-smart, decentralized postal system for cars that uses two main tools: a Relay Chain (a global traffic controller) and Ciphertext-Policy Attribute-Based Encryption (a magical, context-sensitive lock).

Here is how it works, broken down into simple concepts:

1. The Two-Layer City Map (The Architecture)

Imagine the world isn't just one big block, but a series of neighborhoods (Regions).

Regional Blockchains: Each neighborhood has its own local ledger (a digital notebook) where cars in that area write down their data. This keeps things fast because you don't have to wait for a message to travel across the ocean to be recorded.
The Relay Chain: This is the "Global Post Office" connecting all neighborhoods. It doesn't store the actual data, but it holds the rules. It knows which neighborhood is which, who is allowed to read what, and it updates the rules for everyone instantly.

2. The Magic Lock (CP-ABE)

Traditionally, to lock a message, you need a specific key. If you want to share a secret with 50 people, you might have to make 50 copies of the message or manage 50 keys. That's a nightmare.

This paper uses Ciphertext-Policy Attribute-Based Encryption (CP-ABE). Think of this not as a key, but as a bouncer at a club.

Instead of giving a key to a person, you write a rule on the door (the data).
The Rule: "Only people who are a Police Officer AND are in Region A AND have a Badge Number can enter."
If a regular driver tries to open the door, the bouncer says, "Sorry, you don't meet the criteria."
If a police officer from Region A walks up, the bouncer checks their ID, sees they match the rule, and lets them in.

3. The Smart Traffic Light (The Relay Chain's Job)

This is the paper's biggest innovation. Usually, you have to decide before you send a message: "Is this secret? Do I need a super-strong lock?"

In this system, the car (called an OBU) asks the Relay Chain first.

Scenario A (The Accident): A car senses a crash at night in a sensitive zone. It asks the Relay Chain: "Is this important?"
- The Relay Chain says: "YES! This is high security."
- The car then applies a super-tight lock (requiring multiple attributes like "Police" + "Emergency" + "Night Shift") before sending the data.
Scenario B (The Weather): A car senses it's raining. It asks the Relay Chain: "Is this important?"
- The Relay Chain says: "NO, this is just a routine update."
- The car applies a light lock (or maybe no lock at all) so everyone can read it instantly without slowing down traffic.

This "Smart Traffic Light" ensures that critical data is super-secure, but boring data doesn't get bogged down by heavy encryption, keeping the system fast.

4. The "Who Did It?" Feature (Traceability)

What if someone uses their magic key to steal data and then claims, "It wasn't me"?
In this system, every key has a hidden fingerprint baked into it by the Trusted Authority (the government/issuer). Even if a user tries to hide, the system can trace the decryption back to the specific person who used the key. It's like a receipt that proves exactly who opened the safe.

5. Why This is Better Than Old Ways

No Single Point of Failure: Old systems relied on one central server (like a Roadside Unit). If that server got hacked or broke, the whole area went dark. Here, if one neighborhood's blockchain has an issue, the others keep working, and the Relay Chain keeps the rules safe.
Speed: By letting cars encrypt their own data and only storing it locally, we avoid the lag of sending everything to a central cloud.
Flexibility: The rules can change instantly. If a new emergency happens, the Relay Chain updates the "bouncer's rules" for the whole network in seconds.

The Bottom Line

This paper proposes a system where cars act like smart, independent agents. They don't just blindly send data; they ask a global referee (the Relay Chain) how sensitive the data is, lock it up with a magical, rule-based lock (CP-ABE), and store it in their local neighborhood.

It's like having a city where every house has its own vault, but a central mayor decides which vaults need steel doors and which can have glass doors, ensuring that secrets stay secret, but traffic keeps moving fast.

1. Problem Statement

The rapid growth of Intelligent Transportation Systems (ITS) and the Internet of Vehicles (IoV) has created an urgent need for secure, context-aware data sharing mechanisms. Current solutions face several critical challenges:

Centralized Bottlenecks & Single Points of Failure (SPOF): Traditional architectures rely heavily on Roadside Units (RSUs) and centralized cloud storage. If an RSU fails or is compromised, data availability and integrity are lost.
Security vs. Latency Trade-off: High-security encryption (like standard Ciphertext-Policy Attribute-Based Encryption, CP-ABE) is computationally expensive, causing latency unsuitable for real-time vehicular communication. Conversely, skipping encryption for speed compromises data privacy.
Heterogeneity and Scalability: IoV environments span multiple jurisdictions and regions. Existing blockchain solutions often struggle with cross-region data access, interoperability, and efficient revocation of compromised keys across a federated network.
Resource Constraints: On-Board Units (OBUs) in vehicles have limited computational power, making heavy cryptographic operations (like complex pairing operations) impractical without offloading to potentially untrusted servers.

2. Methodology: The RC-CP-ABE Framework

The authors propose a novel architecture called RC-CP-ABE (Relay-Chain-Powered Ciphertext-Policy Attribute-Based Encryption). This system integrates a Relay Chain (global coordinator) with Regional Blockchains (local storage) and a modified CP-ABE scheme.

A. System Architecture

The model consists of six key entities:

On-Board Units (OBUs): Vehicle sensors that generate data. They perform lightweight encryption and interact directly with the relay chain for policy decisions.
Roadside Units (RSUs): Support nodes that assist OBUs with communication or act as proxies if an OBU is temporarily disconnected.
Regional Blockchain: Local ledgers for specific geographic zones (e.g., Region A, Region B) that store encrypted ciphertexts, metadata, and local access policies.
Relay Chain: A global blockchain acting as a controller. It maintains global attribute definitions, revocation lists, and a Smart Contract that dictates encryption policies based on context.
Trusted Authority (TA): A federated entity responsible for system setup, generating master keys, and issuing attribute keys to authorized users (e.g., police, traffic managers).
Authorized Users: Entities capable of decrypting data if their attributes match the ciphertext policy.

B. Core Mechanism: Relay-Guided Context-Aware Encryption

The system introduces a dynamic "switching" mechanism:

Context Query: Before encrypting, an OBU sends metadata (event type, location, time) to the Relay Chain's smart contract.
Policy Decision: The smart contract evaluates the context.
- High Sensitivity (e.g., Night Accident): Returns a "True" flag. The OBU applies a strict CP-ABE policy (e.g., Role=Police AND Region=ZoneA).
- Low Sensitivity (e.g., Weather Update): Returns a "False" flag. The OBU applies a minimal policy or transmits data in plaintext to save latency.
Storage: Encrypted data is stored in the Regional Blockchain. The Relay Chain acts as a global index, allowing users in other regions to locate and retrieve the ciphertext if they possess the correct attributes.

C. Cryptographic Improvements

The authors modified the standard CP-ABE scheme to suit resource-constrained OBUs:

Lightweight Operations: The encryption process is optimized to reduce pairing operations, making it feasible for OBUs to perform end-to-end encryption without RSU offloading.
Traceability: The secret keys include a hidden parameter ( $\Upsilon$ ) derived from the user's identity ( $id_u$ ). This allows the TA to trace any decrypted data back to the specific user who accessed it, preventing key misuse.
Revocation: Revocation lists are managed on the Relay Chain. When a user's attributes are revoked, the smart contract updates the policy, preventing future decryption attempts.
Security Assumptions: The scheme relies on the Decisional Bilinear Diffie-Hellman (DBDH) assumption for confidentiality and the q-Strong Diffie-Hellman (q-SDH) assumption for traceability.

3. Key Contributions

Relay-Guided Context-Aware Switching: A smart contract mechanism that dynamically adjusts encryption strictness based on real-time event sensitivity, balancing security and latency.
Dual-Mode Payload Structure: A unified ciphertext structure ( $CT_f$ ) that can contain either fully encrypted data or plain data under a light policy, simplifying storage and parsing for regional chains.
OBU-Only Encryption: Proof that low-capability OBUs can perform necessary CP-ABE operations independently, eliminating the need for hybrid AES solutions or heavy reliance on RSUs.
Federated Multi-Region Architecture: A two-layer blockchain system (Regional + Relay) that enables seamless cross-jurisdictional data sharing without gateways, ensuring uniform revocation and policy enforcement.

4. Results and Performance Analysis

The authors conducted extensive simulations using the Ethereum testbed (Replit) and the Python-based Charm framework (PBC Library).

Security: The scheme was proven to be IND-CPA secure (indistinguishable under chosen-plaintext attack) and traceable, assuming the hardness of DBDH and q-SDH problems.
Latency:
- Policy Evaluation: Latency increases moderately with user count, indicating efficient attribute checking.
- Upload/Revocation: Latency rises linearly but remains manageable.
- Efficiency: The uploadCiphertext function showed a better efficiency ratio (latency per gas unit) compared to revokeAttribute, though both degrade slightly under high load (5 to 20 users).
Computational Cost:
- Key Generation: The proposed model is faster than existing schemes (Li et al., Zeng et al., Zhao et al.), scaling linearly with a lower constant factor.
- Encryption: The encryption time is almost independent of the attribute set size, remaining constant at approximately 37.75 ms. This is a significant improvement over schemes where encryption time grows with the number of attributes.
- Decryption: The decryption cost is negligible and independent of attribute set size, offering an 83% reduction in decryption time compared to other methods.
Storage Overhead:
- Secret Keys: The proposed model requires the least storage space for secret keys.
- Ciphertext: The ciphertext size is optimized, growing at a lower rate compared to competing schemes as the number of attributes increases.

5. Significance and Conclusion

This paper presents a significant advancement in securing Intelligent Transportation Systems by solving the "security vs. speed" dilemma.

Scalability: By using a relay chain for global coordination and regional chains for local storage, the system scales effectively across different jurisdictions.
Real-World Applicability: The ability for OBUs to perform lightweight encryption makes the system viable for current vehicle hardware without requiring expensive upgrades.
Dynamic Trust: The context-aware switching ensures that critical safety data is heavily protected while routine data flows with minimal latency, optimizing network resources.
Accountability: The built-in traceability mechanism ensures that data leaks can be traced to specific users, enhancing the overall trustworthiness of the IoV ecosystem.

In conclusion, the RC-CP-ABE framework offers a robust, decentralized, and efficient solution for next-generation vehicular networks, effectively balancing real-time responsiveness with rigorous security and privacy requirements.