Blockchain Shared Secret for Chaincode Authentication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current blockchain configurations face challenges in securely authenticating chaincode-to-chaincode invocations, particularly when chaincodes belong to different channels, leading to potential unauthorized access due to mismatched reader permissions.
Innovation Solution
A shared secret is generated and stored outside the blockchain, shared among node members during the setup phase, and used to verify the invoking node during chaincode invocations, ensuring secure access control by confirming the invocation originates from the same node.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If chaincode-to-chaincode invocation authentication is performed based on matching reader lists between caller and callee, then authentication can be performed using existing blockchain permissions, but the invocation will fail when chaincodes belong to different channels with different readers
Solution Approach 1:
The patent introduces a shared secret as an intermediary authentication mechanism between caller and callee chaincodes. This shared secret, stored outside the blockchain in node memory, serves as a mediator that enables authentication without requiring reader list matching. The shared secret is established during a setup phase and used to verify the invoking node's identity, allowing cross-channel invocations while maintaining security.
2Reliability
If a shared secret is stored outside the blockchain in node memory, then authentication becomes more reliable for cross-channel invocations, but the setup complexity and infrastructure requirements increase
Solution Approach 1:
The patent implements a setup phase that performs preliminary actions to establish shared secrets between node pairs before actual chaincode invocations occur. During this setup phase, shared secrets are generated and stored in node memory, and invocation permissions are configured. This preliminary preparation eliminates the need for complex runtime authentication logic and simplifies the actual invocation process.
3Ease of operation
If authentication is based on message proposal from transaction trigger, then the authentication follows the existing blockchain transaction model, but it cannot verify the invoking node for chaincode upgrades
Solution Approach 1:
The patent replaces the message proposal-based authentication mechanism with a shared secret verification mechanism. Instead of relying on the transaction model's message proposals, the system uses cryptographic shared secrets stored in node memory to verify the invoking node's identity. This substitution maintains operational simplicity while enabling verification across different scenarios including chaincode upgrades.
Data Source
AI summary
An example operation may include one or more of creating a shared secret via a blockchain node member, storing the shared secret in a memory outside the blockchain, and sharing the shared secret with one or more other blockchain node members during a setup phase of an execution environment associated with a chaincode.