Container Onboarding Identity Transfer for Secure Host Migration

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing onboarding solutions fail to securely authenticate and integrate containerized applications in industrial systems, as pre-installed cryptographic identities are ineffective and vulnerable to adversaries.

Innovation Solution

A method involving an orchestrator to verify the integrity, authenticity, and execution environment of host devices, provide a trusted root certificate, and assign an onboarding identity using IEEE 802.1AR standards, ensuring secure transfer and integration of components between host devices.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Extent of automation

If pre-installed cryptographic identities are used in containerized applications, then onboarding can be automated, but security is compromised as adversaries can copy containers and impersonate original components

Engineering Contradiction:
Improveonboarding automationVSAvoidsecurity
Core Design Contradiction:
Extent of automationVSReliability

Solution Approach 1:

The patent introduces a host device as an intermediary between the containerized application and the onboarding process. The host device generates and stores the unique onboarding identity (private key and certificate) in its secure memory, while the containerized application only receives a reference to this identity. This mediator approach prevents direct storage of cryptographic material in the application while enabling automated onboarding through the host's secure credentials.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If cryptographic material is stored in hardware-protected memory on host devices, then security is maintained for traditional hardware components, but containerized applications cannot be securely onboarded as they lack persistent storage

Engineering Contradiction:
ImprovesecurityVSAvoidcompatibility with containerized applications
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The host device's secure memory is designed to serve multiple functions: storing the onboarding identity for containerized applications, maintaining system security credentials, and providing persistent storage where container applications cannot. This universal secure storage mechanism enables the same hardware security infrastructure to support both traditional hardware components and modern containerized applications.

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Productivity

If containerized applications are shifted between host devices, then resource utilization is improved, but onboarding security becomes challenging as the same application may appear on multiple hosts

Engineering Contradiction:
Improveresource utilizationVSAvoidonboarding security
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent extracts the onboarding identity from the containerized application and relocates it to the host device's secure memory. The application itself contains only a reference or placeholder, while the actual cryptographic credentials (private key and certificate) are stored in the host's secure memory space. This extraction ensures that when applications are shifted between hosts, only the reference moves with the application, while the secure credentials remain tied to the destination host.

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentUS12536253B2Secure onboarding of a component in a network
Publication Date: 2026.01.27 ABB (SCHWEIZ) AG
  • US12536253B2 patent drawing
  • US12536253B2 patent drawing
  • US12536253B2 patent drawing

AI summary

A method for providing a secure onboarding of a component from at least one first host device into a second host device includes verifying the integrity, authenticity and/or execution environment of the first host device by an orchestrator; providing a trusted root certificate to the second host device by the orchestrator; providing an onboarding identity by the orchestrator to the first host device, when the integrity, the authenticity and/or the execution environment of the first host device has been verified; receiving the onboarding identity from the orchestrator by the first host device and assigning the onboarding identity to the component; providing the assigned onboarding identity to the second host device; and securely onboarding the component from the first host device into the second host device based on the assigned onboarding identity and the provided trusted root certificate.