Hot-Swappable Software Component Updates via Hash Chain Verification

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current methods for updating software components are coarse-grained, slow, and limited in granularity, often requiring the software to be offline, and lack effective security measures to prevent roll-back and differential attacks, especially in response to security breaches.

Innovation Solution

A fine-grained mechanism for updating software components using cryptographic hash chains and data tables, allowing for dynamic loading of 'hot-swappable' components with anti-rollback and anti-roll-forward features, enabling flexible updates while maintaining security and performance, applicable across various operating systems.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If dynamic library mechanisms are used for updating components, then component updatability is improved, but performance overhead increases due to runtime symbol resolution

Engineering Contradiction:
Improvecomponent updatabilityVSAvoidruntime performance
Core Design Contradiction:
Adaptability or versatilityVSSpeed

Solution Approach 1:

The patent pre-resolves relocatable symbols and prelinks components at build time, creating a static linkage structure. This preliminary action eliminates the need for runtime symbol resolution, thus maintaining performance while enabling component updates through a different mechanism (component replacement rather than dynamic linking).

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent divides the program into static base components and updatable component modules. This segmentation allows specific components to be updated without affecting the entire program, achieving fine-grained updatability without the performance overhead of dynamic linking the entire program.

Inventive Principle:
Principle #1Segmentation

2Adaptability or versatility

If full program updates are performed at any renewal, then any part of the program may be changed, but sizable upload data and code are required

Engineering Contradiction:
Improveprogram modifiabilityVSAvoidupload data size
Core Design Contradiction:
Adaptability or versatilityVSQuantity of substance

Solution Approach 1:

The patent segments the program into a static base and separate component modules. Only the specific component modules requiring updates need to be uploaded, rather than the entire program. This enables targeted updates with minimal data transfer while maintaining the ability to modify any program part.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent extracts specific component modules from the full program, allowing these extracted components to be updated independently. This extraction enables updating only the necessary portions of the program, reducing upload data requirements while maintaining full program modifiability.

Inventive Principle:
Principle #2Taking out (Extraction)

3Adaptability or versatility

If data files control paths of control-flow, then behaviour can be changed at run-time, but renewability is limited and code protection is weakened

Engineering Contradiction:
Improveruntime behaviour changeVSAvoidcode protection and renewability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent uses cryptographic hash chains to create verified copies of component modules. Each component has an associated hash value that serves as a cryptographic copy/representation, enabling verification of component integrity and authenticity without exposing the actual code, thus protecting code while enabling updates.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The patent introduces cryptographic hash values as an intermediary between the control system and the actual component code. The hash chain mechanism mediates the verification process, allowing the system to control and verify components without directly handling or exposing the sensitive code itself.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Productivity

If updates are performed while software is running, then continuous operation is maintained, but confidence in update loading is reduced

Engineering Contradiction:
Improvesystem availabilityVSAvoidupdate loading confidence
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent implements cryptographic verification (hash chain validation) as feedback mechanism for update loading. Before loading an updated component, the system verifies its integrity through cryptographic hash verification, providing confidence in the update's authenticity even while the system remains operational.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The patent performs preliminary cryptographic verification of component integrity before loading updated components into the running system. This preliminary validation action ensures update confidence is established prior to execution, maintaining both system availability and update reliability.

Inventive Principle:
Principle #10Preliminary action

5Adaptability or versatility

If existing update mechanisms are used, then functional updates are supported, but security responses to breaches are not well supported

Engineering Contradiction:
Improvefunctional update capabilityVSAvoidsecurity response capability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent implements preliminary anti-actions against security threats through cryptographic verification mechanisms. Hash chains provide pre-established verification capabilities that prevent unauthorized modifications and enable detection of security breaches before they can compromise the system, going beyond simple functional updates.

Inventive Principle:
Principle #9Preliminary anti-action

Solution Approach 2:

The patent converts the potential harm of code modification into a benefit by using cryptographic hash verification. The same mechanism that allows code to be updated also provides security verification, turning the update process itself into a security feature rather than a vulnerability.

Inventive Principle:
Principle #22Blessing in disguise (Convert harm into benefit)

Data Source

PatentEP2828745B1Updating software components
Publication Date: 2020.01.08 IRDETO BV
  • EP2828745B1 patent drawingFigure 1
  • EP2828745B1 patent drawingFigure 2
  • EP2828745B1 patent drawingFigure 3

AI summary

A method and system for renewing software at the component-level is provided. A client program includes a base component for loading a software component into at least one loadable region of the program to update the program. Code in the software component is for writing state data associating the state of the update in storage, upon execution of the software component, and testing the state data to verify condition of the updated program and disallowing rollback and roll-forward attacks, the state data comprising hash chain values. The state data for verifying the correctness of the updated program is entangled with application data used for the program functionality. A server includes: an update pool having a plurality of software updates deployed in each client, and a policy control for monitoring and controlling at least one of: the length of time the client runs until the software update is invoked, a chain of the updates; and the granularity of the update.