Shared Matrix Construction for IoT Cryptographic Protocols

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing cryptographic protocols based on shared matrices face challenges in resource-restricted environments, such as the Internet of Things, due to the large overhead of sharing and storing large matrices, which can lead to security vulnerabilities like pre-computation attacks and denial-of-service attacks.

Innovation Solution

An electronic network node configuration that reduces the overhead by using selection data to construct shared matrices, where the selection data requires fewer bits than the actual matrix values, allowing for efficient transmission and computation, and caching or generating sequences of values for multiple connections, thereby reducing the computational and bandwidth requirements.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a large shared matrix is transmitted between nodes, then cryptographic security is maintained, but bandwidth overhead and transmission time increase significantly

Engineering Contradiction:

Improvecryptographic securityVSAvoidbandwidth overhead

Core Design Contradiction:

ReliabilityVSQuantity of substance

Solution Approach 1:

The patent extracts only the essential selection data from the full shared matrix, transmitting merely the indices or selection parameters rather than the complete matrix values. This allows nodes to reconstruct the necessary matrix portions locally, dramatically reducing bandwidth overhead while preserving cryptographic security.

Inventive Principle:

Principle #2Taking out (Extraction)

Solution Approach 2:

The shared matrix is segmented into multiple parts, with only the selection data for specific entries being transmitted. The actual matrix values are generated locally at each node through deterministic computation, dividing the transmission burden and reducing overall data volume.

Inventive Principle:

Principle #1Segmentation

2Reliability

If a fresh shared matrix is generated for each cryptographic execution, then pre-computation attacks are prevented, but computational overhead and generation time increase

Engineering Contradiction:

Improveresistance to pre-computation attacksVSAvoidmatrix generation time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

A master sequence of values is pre-generated and stored at both nodes before cryptographic execution. This preliminary action allows the actual shared matrix to be quickly constructed during protocol execution by simply selecting from the pre-computed sequence, preventing pre-computation attacks while minimizing generation time.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The patent changes the parameter representation from full matrix values to compact selection indices. By transmitting and computing with these compressed parameters instead of complete matrix entries, the system achieves both security against pre-computation and reduced computational overhead.

Inventive Principle:

Principle #35Parameter changes

3Ease of operation

If resource-restricted nodes store large shared matrices, then cryptographic operations can be performed, but memory requirements and storage overhead increase

Engineering Contradiction:

Improvecryptographic operation capabilityVSAvoidmemory requirements

Core Design Contradiction:

Ease of operationVSVolume of stationary object

Solution Approach 1:

Instead of storing the full shared matrix, nodes store a compact representation (selection data or seed) that can be used to deterministically generate or reconstruct the necessary matrix portions. This copying approach reduces memory requirements while maintaining full cryptographic operation capability.

Inventive Principle:

Principle #26Copying

Solution Approach 2:

The shared matrix transitions from a static stored object to a dynamically generated structure. Nodes compute matrix values on-demand during cryptographic operations rather than storing them permanently, adapting the storage requirements to the actual operational needs and significantly reducing memory footprint.

Inventive Principle:

Principle #15Dynamics

4Quantity of substance

If selection data is used to construct shared matrices, then bandwidth overhead is reduced, but computational complexity at the receiving node increases

Engineering Contradiction:

Improvetransmission data sizeVSAvoidmatrix construction complexity

Core Design Contradiction:

Quantity of substanceVSDevice complexity

Solution Approach 1:

The receiving node uses its own pre-stored master sequence and the received selection data to autonomously construct the shared matrix without requiring additional computational assistance from the transmitting node. This self-service approach shifts computational burden to local resources, reducing network complexity.

Inventive Principle:

Principle #25Self-service

Solution Approach 2:

The master sequence of values is pre-computed and stored at both nodes before the cryptographic protocol execution. This preliminary computation simplifies the runtime matrix construction process, as nodes only need to perform simple selection and assembly operations rather than complex matrix generation during the actual protocol.

Inventive Principle:

Principle #10Preliminary action

Data Source

PatentUS11212098B2Device and method sharing a matrix for use in a cryptographic protocol

Publication Date: 2021.12.28 KONINKLIJKE PHILIPS NV

AI summary

A network node (110) is provided configured for a cryptographic protocol based on a shared matrix. The network node is arranged to construct the shared matrix (A) in accordance with the selection data and a shared sequence of values. Multiple entries of the shared matrix are assigned to multiple values of the sequence of data as assigned by the selection data. The shared matrix is applied in the cryptographic protocol.