Lightweight Node Authentication via Blockchain Consensus

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Decentralized networks of lightweight nodes face challenges in authentication due to reliance on certificate authorities, leading to centralized systems with single points of failure, delays, and vulnerability to attacks, especially in IoT devices with limited storage capacity.

Innovation Solution

Implementing a lightweight blockchain consensus algorithm that allows unenrolled nodes to request enrollment through a trusted node and peers, using tokens and signatures to authenticate and establish secure connections without relying on full nodes, thereby decentralizing authentication and reducing communication overhead.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a certificate authority is used to authenticate lightweight nodes in a decentralized network, then security and authentication reliability are improved, but the system becomes centralized with a single point of failure and increased vulnerability to attacks

Engineering Contradiction:
Improveauthentication reliabilityVSAvoiddecentralization capability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent extracts the authentication function from the centralized certificate authority and distributes it to lightweight nodes through blockchain technology. Nodes can independently verify each other's authenticity by checking the blockchain ledger, eliminating the single point of failure while maintaining security.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The blockchain acts as an intermediary between lightweight nodes, providing a decentralized trust mechanism. Instead of relying on a certificate authority, nodes use the blockchain's distributed ledger and consensus algorithms to establish trust and verify identities peer-to-peer.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If full nodes are used to store the entire blockchain, then complete authentication data is available, but storage requirements increase significantly (up to 300 GB)

Engineering Contradiction:
Improveauthentication data completenessVSAvoidstorage capacity
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The patent segments the blockchain data into two parts: block headers (stored by lightweight nodes, approximately 1/1000 of total blockchain size) and full transaction data (stored by full nodes). This segmentation allows lightweight nodes to perform authentication with minimal storage while full nodes maintain complete data for complex operations.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Lightweight nodes perform partial authentication by verifying only the necessary block headers and relevant transaction data through SPV techniques, rather than storing and processing the entire blockchain. This partial action is sufficient for authentication purposes while dramatically reducing storage requirements.

Inventive Principle:
Principle #16Partial or excessive action

3Quantity of substance

If lightweight nodes store only block headers and use SPV techniques, then storage requirements are reduced, but authentication of other lightweight nodes becomes challenging and reliant on full nodes

Engineering Contradiction:
Improvestorage capacityVSAvoidauthentication operation
Core Design Contradiction:
Quantity of substanceVSEase of operation

Solution Approach 1:

The patent enables lightweight nodes to perform self-service authentication by storing relevant public keys and enrollment data locally. Nodes can independently verify other lightweight nodes' identities using their stored data and blockchain headers without requiring full nodes, making the authentication process self-sufficient.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

Lightweight nodes perform preliminary authentication by storing essential verification data (public keys, enrollment transactions) during the node enrollment phase. This preliminary action prepares them for future authentication operations, eliminating the need for continuous full node dependency.

Inventive Principle:
Principle #10Preliminary action

4Reliability

If a certificate is used to bind a node's public key to its identity, then security is improved, but the certificate size (e.g., X.509 at 3KB) increases storage and communication overhead

Engineering Contradiction:
ImprovesecurityVSAvoidcertificate management complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent replaces traditional X.509 certificates with simplified cryptographic proofs stored on the blockchain. Instead of managing complex certificate structures with multiple fields and validation rules, nodes use compact cryptographic signatures and Merkle proofs that provide equivalent security with minimal overhead.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The patent changes the fundamental parameters of authentication from certificate-based security (with fixed structures, expiration dates, and hierarchical validation) to blockchain-based cryptographic proofs. This parameter change simplifies the authentication mechanism while maintaining security through immutable ledger verification and consensus algorithms.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS20240430104A1Device Authentication using Blockchain
Publication Date: 2024.12.26 CEREMORPHIC INC
  • US20240430104A1 patent drawing
  • US20240430104A1 patent drawing
  • US20240430104A1 patent drawing

AI summary

An unenrolled lightweight node is on a decentralized network with a trusted node and a plurality of peers. The unenrolled lightweight node and the peers run a lightweight blockchain consensus algorithm. The unenrolled lightweight node includes (a) circuitry for storing a token that includes a signature that includes at least a signature of at least a first identifier signed with a private key of the trusted node, the first identifier being associated with a public key of the unenrolled lightweight node, and (b) circuitry for broadcasting a request for blockchain enrollment of the unenrolled lightweight node to the plurality of peers. The authentication request including at least a second identifier that is associated with at least a public key of the unenrolled lightweight node, a signature created with at least the second identifier and a corresponding private key of the unenrolled lightweight node, and the token.