File Integrity Check via Hash Verification and Erasure

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing data storage systems face challenges in maintaining an uninterrupted chain of evidence while allowing for the secure and provable erasure of data, particularly due to privacy and legal requirements that conflict with the integrity of the evidence.

Innovation Solution

Implementing a data storage system with an integrity check mechanism that uses hashing and audit logs to verify the integrity of files and metadata, allowing for the secure deletion of data by replacing content with an erased marker and logging all changes and accesses, while utilizing a Merkle tree structure for efficient hashing of large files.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If data is erased to meet privacy and legal requirements, then data security and compliance are improved, but the chain of evidence is broken

Engineering Contradiction:
Improvedata securityVSAvoidchain of evidence
Core Design Contradiction:
ReliabilityVSLoss of information

Solution Approach 1:

The patent creates cryptographic copies (hashes) of the original data that serve as permanent evidence records. When data is erased, its cryptographic hash remains in the system, providing a verifiable copy that proves the data's existence and integrity without retaining the actual content. This resolves the contradiction by maintaining evidence through cryptographic copies while allowing physical data erasure.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The patent introduces cryptographic hash functions as intermediaries between the original data and the evidence chain. The hash acts as a mediator that links the erased data to its evidence record without requiring the original data to persist. This intermediary mechanism allows data deletion while preserving the evidentiary connection through the immutable hash reference.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Loss of information

If data is retained to maintain chain of evidence, then evidence integrity is preserved, but privacy and security requirements cannot be met

Engineering Contradiction:
Improvechain of evidenceVSAvoidprivacy risk
Core Design Contradiction:
Loss of informationVSObject-affected harmful factors

Solution Approach 1:

The system creates cryptographic copies (hashes) of sensitive data that contain all evidentiary value but no actual content. These hash copies replace the need to retain original sensitive data, preserving the chain of evidence while eliminating privacy risks associated with storing actual personal or confidential information.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The patent extracts the essential evidentiary property from the data by computing its cryptographic hash. This extraction separates the proof of existence and integrity (the hash) from the sensitive content itself, allowing the system to retain only the non-sensitive hash while discarding or erasing the harmful sensitive data.

Inventive Principle:
Principle #2Taking out (Extraction)

3Measurement precision

If traditional hashing is used to verify data integrity, then verification is achieved, but it cannot prove data deletion

Engineering Contradiction:
Improveintegrity verificationVSAvoiddeletion verification capability
Core Design Contradiction:
Measurement precisionVSProductivity

Solution Approach 1:

The patent inverts the traditional hashing approach by hashing the data before storage and keeping the hash as the primary reference. When deletion is requested, the system checks whether the hash still points to valid data. If the data is successfully deleted, the hash will fail to resolve, providing positive proof of deletion. This inversion transforms hashing from a verification-only tool into a deletion-proof mechanism.

Inventive Principle:
Principle #13The other way round (Inversion)

Data Source

PatentUS10440033B2Data storage system file integrity check
Publication Date: 2019.10.08 SAP SE
  • US10440033B2 patent drawing
  • US10440033B2 patent drawing
  • US10440033B2 patent drawing

AI summary

An integrity check for a first file is initiated. In response, a first key corresponding to the first file is obtained. The first file is hashed to determine that the first key is not equivalent to the hashed first file. A second key is then obtained that corresponds to the hashed first file. A second file is then obtained using the second key. This second file is hashed to determine whether the second key is equivalent to the hashed second file. Integrity of the first file is confirmed if the second key is equivalent to the hashed second file or integrity of the first file is rejected if the second key is not equivalent to the hashed second file. Related apparatus, systems, techniques and articles are also described.