ASIC-Based Device Attestation via Computation Speed Verification

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional device attestation methods rely on private keys and third-party services, which are costly and insecure, and can be circumvented by software emulators, lacking a reliable way to verify the trustworthiness of computing devices without shared keys.

Innovation Solution

A computing device attests itself to a communication partner using an Application-Specific Integrated Circuit (ASIC) that generates a verification value through a predefined cryptographic function, eliminating the need for private keys and third-party services by leveraging dedicated computation modules for secure data communication.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If conventional device attestation uses unique private keys, then device identity can be verified, but deployment cost becomes prohibitively expensive

Engineering Contradiction:
Improvedevice identity verificationVSAvoiddeployment cost
Core Design Contradiction:
ReliabilityVSEase of manufacture

Solution Approach 1:

The patent extracts the attestation verification function from the device hardware itself and performs it remotely on the server. Instead of requiring expensive secure hardware modules in each device, the server extracts and verifies device characteristics software-based, eliminating the need for costly physical security modules while maintaining attestation reliability

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent creates a software-based copy of the device's identification and verification functionality. Rather than requiring physical secure elements, the system uses software emulators that replicate device characteristics, allowing multiple virtual instances to be created without additional hardware costs

Inventive Principle:
Principle #26Copying

2Reliability

If conventional device attestation uses third-party services, then attestation can be performed, but the third party requirement becomes inconvenient

Engineering Contradiction:
Improveattestation capabilityVSAvoidconvenience
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The patent enables the server to perform attestation independently without requiring external third-party services. The server itself has the capability to extract device characteristics, compute verification values, and make authentication decisions, making the system self-sufficient and eliminating dependency on external attestation authorities

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent makes the server multi-functional by integrating both the application server functions and the attestation verification functions into a single system. The server can simultaneously provide service functionality and perform security verification, eliminating the need for separate dedicated attestation infrastructure

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

3Ease of manufacture

If single shared key is used for device attestation, then deployment is simplified, but security is compromised when key is extracted

Engineering Contradiction:
Improvedeployment simplicityVSAvoidsecurity
Core Design Contradiction:
Ease of manufactureVSReliability

Solution Approach 1:

The patent applies different verification approaches to different device characteristics. Instead of using a single shared key for all devices, the system extracts and verifies unique device-specific characteristics (such as hardware identifiers, processor features, or memory characteristics) for each device, providing localized security tailored to each device's unique properties while maintaining simplified deployment

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent changes the parameter used for verification from a static shared key to dynamic device-specific characteristics. The verification parameter is derived from actual device hardware properties rather than a pre-shared secret, making extraction useless to attackers while maintaining deployment simplicity through software-based verification

Inventive Principle:
Principle #35Parameter changes

4Object-affected harmful factors

If private key is extracted from device, then conventional attestation can be circumvented, but software emulator using extracted key can still mimic trusted device

Engineering Contradiction:
Improveattestation circumventionVSAvoidemulator detection
Core Design Contradiction:
Object-affected harmful factorsVSReliability

Solution Approach 1:

The patent performs preliminary verification of device characteristics before authentication. The server extracts and verifies multiple device properties (hardware identifiers, processor characteristics, memory features) before granting access, creating a preliminary security barrier that prevents emulators from mimicking trusted devices even if they possess extracted keys

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent uses a composite verification approach combining multiple device characteristics (hardware identifiers, processor features, memory characteristics, and other hardware properties) to create a multi-layered authentication mechanism. This composite verification makes it difficult for software emulators to replicate all required characteristics simultaneously, even with extracted private keys

Inventive Principle:
Principle #40Composite materials

Data Source

PatentEP4235468A2Systems, methods and apparatuses for device attestation based on speed of computation
Publication Date: 2023.08.30 OLOGN TECH AG
  • EP4235468A2 patent drawingFigure 1
  • EP4235468A2 patent drawingFigure 2
  • EP4235468A2 patent drawingFigure 3

AI summary

The systems, methods and apparatuses described herein provide a computing device that is configured to attest itself to a communication partner. In one aspect, the computing device may comprise a communication port configured to receive an attestation request from the communication partner, and an application-specific integrated circuit (ASIC). The ASIC may be configured to receive the attestation request, which may include a nonce. The ASIC may be further configured to generate a verification value, capture data representing a state of computation of the ASIC when the verification value is being generated, and send the verification value and captured data to the communication port to be transmitted back to the communication partner. The verification value may be a computation result of a predefined function taking the nonce as an initial value. In another aspect, the communication partner may be configured to attest the computing device using speed of computation attestation.