Device Hash Integrity Verification via RTC Synchronization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional integrity verification methods are vulnerable to replay attacks, where attackers use pre-stolen hashes to compromise device integrity, especially in IoT and cloud technologies.
Innovation Solution
A security system that includes a device connected to a platform, utilizing real-time clock (RTC) data and main firmware hashes to generate a device hash, which is verified by the platform's root of trust (RoT) to ensure integrity, preventing replay attacks by synchronizing RTC data and using nonce data to authenticate the hash.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional integrity verification methods are used, then the verification process is simple, but the system is vulnerable to replay attacks where attackers use pre-stolen hashes
Solution Approach 1:
The system performs preliminary actions by storing the original firmware image in secure storage before verification, and by pre-synchronizing RTC data between platform and device. This allows the verification process to compare current firmware against the stored original, preventing replay attacks where attackers use pre-stolen hashes, as the verification is tied to both the original firmware and time-synced RTC data.
Solution Approach 2:
The patent introduces an intermediary verification mechanism that uses RTC data as a mediator between the firmware hash and the verification result. The RTC data acts as a time-based intermediary that prevents replay attacks, as the verification requires not just matching firmware hashes but also synchronized RTC data, creating an intermediate layer of security validation.
2Reliability
If RTC data synchronization is implemented to prevent replay attacks, then security against replay attacks improves, but the verification process requires additional time for synchronization
Solution Approach 1:
RTC data synchronization is performed as a preliminary action before the integrity verification process begins. By pre-synchronizing the RTC data between platform and device, the system eliminates the need for time-consuming synchronization during verification, thus preventing replay attacks without significantly increasing verification time.
Solution Approach 2:
The device maintains its own RTC data and automatically keeps it synchronized with the platform's RTC data. This self-service approach to time synchronization reduces the time burden on the verification process, as the device independently manages its timekeeping rather than requiring real-time synchronization during verification.
3Measurement precision
If device hash generation uses both RTC data and firmware hash, then integrity verification accuracy improves, but the hash generation complexity increases
Solution Approach 1:
The system merges the firmware hash and RTC data into a single device hash through concatenation or combination operations. This merging approach improves integrity verification accuracy by incorporating both firmware integrity and time synchronization status, while the combination process itself remains computationally simple, avoiding excessive complexity in hash generation.
Solution Approach 2:
The device hash is created as a composite of firmware hash and RTC data, similar to composite materials combining different properties. This composite hash structure improves verification accuracy by incorporating multiple verification dimensions (firmware integrity and time synchronization), while the composite nature allows for systematic and manageable generation processes.
Data Source
AI summary
A device connected to a platform includes a security system having device-real-time-clock (RTC) data and main firmware communicating with the platform. The security system generates a device hash from the device RTC data and the main firmware hash, and the main firmware provides a response including the device hash to the platform.