Secure Boot Patch Verification with Cumulative SHA

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing secure boot download systems are inefficient due to the need for complete patch verification using encryption algorithms, which cannot be performed until the entire patch is downloaded, especially in systems with unreliable transport conditions where packets may be transmitted out of sequence or retransmitted.

Innovation Solution

Implementing a system where the target device performs security verification computations, such as SHA and RSA, cumulatively and in parallel with packet reception, allowing for efficient verification even with out-of-sequence or retransmitted packets, and reporting the security status only after the entire patch is downloaded to maintain security.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If encryption verification is performed only after the entire patch is downloaded, then security is maintained, but download time and processing efficiency are significantly increased

Engineering Contradiction:
ImprovesecurityVSAvoiddownload time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent performs preliminary encryption verification computations (such as SHA and RSA) on individual packets or chunks of the patch download as they are received, rather than waiting for the entire patch to be downloaded. This preliminary action allows verification to proceed in parallel with the download process, significantly reducing total verification time while maintaining security through cumulative verification of all received data

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The verification process continues continuously as packets are received, with cryptographic computations performed on each incoming packet and cumulative verification results maintained. This continuous verification approach eliminates idle time during download and ensures security is verified throughout the entire process, not just at the end

Inventive Principle:
Principle #20Continuity of useful action

2Reliability

If packets are transmitted out of sequence or retransmitted due to unreliable transport conditions, then transport robustness is improved, but verification complexity and time are increased

Engineering Contradiction:
Improvetransport robustnessVSAvoidverification complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system performs preliminary verification computations on each packet as it arrives, maintaining cumulative verification state. When packets arrive out of sequence or are retransmitted, the verification engine can process them in any order using the cumulative approach, eliminating the need to wait for sequential arrival and reducing verification complexity under unreliable transport conditions

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The verification system changes its operational parameters to handle out-of-sequence packets by implementing cumulative verification where each packet's verification result is combined with previous results. This parameter change in the verification approach allows flexible processing of packets regardless of arrival order, reducing complexity compared to requiring strict sequential verification

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS10375209B2Secure boot download computations based on host transport conditions
Publication Date: 2019.08.06 INTEL CORP
  • US10375209B2 patent drawing
  • US10375209B2 patent drawing
  • US10375209B2 patent drawing

AI summary

Systems, methods and computer readable media enable secure patch downloading from a host to a target with improved security computation operations based on transport conditions. The method may include receiving a packet of the patch from the host; verifying that the packet is not a retransmission of a previously received packet; if the verification succeeds, performing a first type of security computation based on the packet; if the verification fails and the content of the packet differs from the content of the previously received packet, stopping further performance of the first type of security computation until a final packet of the patch is received; performing a second type of security computation based on one or more of the received packets; and determining a security status of the patch based on a comparison of the first type of security computation and the second type of security computation.