Hybrid Certificate Issuance for Post-Quantum IoT Interoperability

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The challenge lies in providing certificates according to different standards, particularly in the context of hybrid cryptography for X.509 certificates, which is essential for securing digital communications, especially for resource-limited devices in the IoT and embedded systems ecosystem, where inadequate storage capacity and computational resources pose significant challenges due to the evolving nature of post-quantum cryptography.

Innovation Solution

A certification authority device capable of generating and managing multiple types of certificates, including hybrid and non-hybrid certificates, using both pre-quantum and post-quantum algorithms, to accommodate diverse device capabilities and ensure interoperability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If hybrid cryptography with multiple certificate types is implemented, then security and future-proofing are improved, but device complexity and storage requirements increase

Engineering Contradiction:
ImprovesecurityVSAvoidcertificate management complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments certificate management by creating separate processing paths for different certificate types (traditional and post-quantum). The system divides the certificate lifecycle into distinct operations: issuance, storage, and validation, each handling specific certificate formats independently. This segmentation allows legacy devices to use traditional certificates while quantum-ready devices use post-quantum certificates, reducing overall system complexity.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements a universal certificate management framework that can handle multiple certificate types through a common interface. The validation mechanism is designed to work with both traditional X.509 certificates and post-quantum certificates uniformly. This multi-functionality allows the same infrastructure to support evolving cryptographic standards without requiring separate systems for each certificate type.

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

2Reliability

If post-quantum certificates are issued for all devices, then future security is ensured, but storage capacity and computational resources are overwhelmed

Engineering Contradiction:
Improvefuture securityVSAvoidstorage capacity
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The patent applies local quality by tailoring certificate issuance to specific device characteristics. Resource-constrained devices receive traditional certificates that occupy less storage space and require fewer computational resources for processing. Meanwhile, devices with adequate resources receive post-quantum certificates for enhanced security. This localized approach ensures each device receives the appropriate certificate type based on its specific capabilities and requirements.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The system dynamically changes certificate parameters based on device capabilities. For resource-limited devices, certificates with smaller key sizes and simpler structures are issued. For capable devices, full post-quantum certificates with larger key sizes are provided. This parameter adaptation allows the system to optimize the balance between security levels and resource consumption across the device ecosystem.

Inventive Principle:
Principle #35Parameter changes

3Adaptability or versatility

If multiple certificate types are supported, then interoperability is improved, but processing time and computational overhead increase

Engineering Contradiction:
ImproveinteroperabilityVSAvoidcertificate validation time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent implements preliminary action through pre-computation and caching mechanisms. Certificate validation rules and cryptographic parameters are pre-configured for different certificate types. The system performs preliminary checks to quickly identify certificate types and route them to appropriate validation paths, avoiding redundant processing steps during actual validation operations.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The validation system dynamically adapts its processing based on the encountered certificate type. When a traditional certificate is detected, the system activates optimized validation paths for faster processing. When post-quantum certificates are encountered, the system switches to appropriate quantum-resistant validation algorithms. This dynamic behavior ensures optimal processing speed for each certificate type while maintaining comprehensive interoperability support.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentEP4683271A1Certification authority device, a subject device and a method for operating a certification authority device
Publication Date: 2026.01.21 SIEMENS AG
  • EP4683271A1 patent drawingFigure 1
  • EP4683271A1 patent drawingFigure 2
  • EP4683271A1 patent drawingFigure 3

AI summary

The invention relates to a certification authority device (22) configured to: receive a public key message from an subject device, the public key message comprising a public key set, comprising a post-quantum public key related to a respective post-quantum cryptographic algorithm, a pre-quantum public key (18) related to a respective pre-quantum cryptographic algorithm, generate a certificate set according to a selected certificate set type of a group of supported certificate set types, the certificate set comprising at least one certificate, wherein the at least one certificate comprises the post-quantum public key and a post-quantum signature and/or the pre-quantum public key (18) and a pre-quantum signature; receive a first certificate request message (24) comprising a first request to provide a first certificate set (26) according to a first certificate set type; send a first certificate response message (34) comprising the first certificate set (26); receive a second certificate request message (36) comprising a second request to provide a second certificate set (30) according to a second certificate set type different from the first certificate set type; and send a second certificate response message comprising the second certificate set (30) according to the second certificate set type.