Cryptographic Data Interface With Latched Control Blocks
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing cryptographic processing systems face challenges in message processing latency and robustness due to the need for interleaved control and data blocks, with many control blocks being duplicative and inefficient.
Innovation Solution
A mechanism is introduced to latch control blocks and reuse them, using an internal counter or write control signal to manage data transfer, reducing the need for repeated control block transmission.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If control blocks and data blocks are interleaved in traditional cryptographic processing, then data can be processed securely, but message processing latency increases and processing efficiency decreases
Solution Approach 1:
The patent applies preliminary action by latching control blocks in advance before data blocks arrive. The data interface latches control blocks as they are received, so when data blocks become available, the processing can immediately begin without waiting for control block transmission. This reduces message processing latency while maintaining secure processing requirements.
Solution Approach 2:
The patent introduces a latch mechanism as an intermediary between the data interface and the cryptographic engine. This latch temporarily stores control blocks, allowing data blocks to be processed independently once the control block is latched. This mediator decouples the strict interleaving requirement, reducing processing latency while maintaining security.
2Ease of operation
If control blocks are transmitted with every data block, then processing control is maintained, but data transfer volume increases by nearly one-third
Solution Approach 1:
The patent extracts the control block transmission requirement from every data block. Instead of sending a control block with each data block, the system latches control blocks and reuses them for multiple data blocks. This removes the redundant control block transmissions, reducing data transfer volume by nearly one-third while maintaining processing control through the latch mechanism.
Solution Approach 2:
The patent applies discarding and recovering by latching control blocks for reuse. Once a control block is latched, it is recovered and reused for subsequent data blocks instead of being discarded and requiring re-transmission. This reduces the overall quantity of data that needs to be transferred while maintaining processing control.
3Quantity of substance
If control blocks are latched and reused, then data transfer volume is minimized, but system complexity increases
Solution Approach 1:
The latch mechanism serves as a simple intermediary that adds minimal complexity to the system. It temporarily stores control blocks and makes them available for processing, enabling data block independence without requiring complex coordination protocols. The added complexity is limited to the latch structure itself, while the overall system becomes more efficient.
Solution Approach 2:
The data interface performs self-service by automatically latching control blocks as they are received, without requiring external coordination or complex control logic. This self-latching mechanism simplifies the overall system architecture while achieving the goal of reducing data transfer volume through control block reuse.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
In accordance with various embodiments of the present disclosure, a processing system (100, 200, 500) is provided. In some embodiments, the processing system (100, 200, 500) comprises a non-secure processing unit (125, 225, 525) and a cryptographic coprocessing unit (115, 215, 515). The cryptographic coprocessing unit (115, 215, 515) comprises a data interface (250, 550) and a hardware cryptographic engine (235, 535). The data interface (250, 550) is configured to receive, from the non-secure processing unit, one or more control blocks (CTRL) and one or more data block (DATA). The hardware cryptographic engine (235, 535) is configured to process, as a function of a cryptographic key, the one or more control blocks (CTRL) and the one or more data blocks (DATA) received by the data interface (250, 550). The data interface (250, 550) is configured to receive a first control block (CTRL) from the non-secure processing unit (125, 225, 525), latch (260, 560) the received first control block (CTRL), receive a first data block (DATA) from the non-secure processing unit (125, 225, 525) and transfer the latched first control block (CTRL) and the received first data block (DATA) to the hardware cryptographic engine (235, 535).