2

I am looking for an approach to verify that some information has not been modified after a certain point in time.

Let's assume a data provider records a data set at time X and provides it to a data consumer at time X+10. How could an approach look like in which the data consumer could now verify that the data set has not been manipulated by the data provider since time X?

Of course, a PKI can be used for authentication and authorization. In this case, however, it is not only important to know from whom the data comes, but also that it has not been changed from the data provider after a specfic timestamp.

I thought maybe the data provider could hash the recorded data and sign it with his private key. The signatures would now have to be stored in a trusted location. For this, a blockchain came to my mind at first. After receiving the record the data consumer, could retrieve the corresponding signature from blockchain and verify it against the received record.

But since I am not an IT security expert, I wanted to ask what solutions already exist for such a problem?

3
  • 1
    There's solutions involving an oracle: en.wikipedia.org/wiki/Trusted_timestamping
    – pjc50
    May 2, 2022 at 14:30
  • There is no solution without a trusted party, because the computer could just have its clock chip updated with one that ticks twice as quickly on command, and then whatever it thinks happened at X actually happened at X+5.
    – user253751
    May 3, 2022 at 10:49
  • Well, there are "verifiable delay functions", but you don't want to go there unless you really like cryptocurrency type stuff, because they require the server to constantly waste power doing computations just for the sake of proving it is doing computations.
    – user253751
    May 3, 2022 at 10:50

4 Answers 4

1

Without additional information, the data consumer can only know that the data set was signed before time X+10, because that's when he got the signed data set. It is impossible for them to see whether the signature was created at time X or time X+10-epsilon, so the data set could have been modified in the time between.

To solve this, the data producer must prove that his signature existed at time X, for example by providing the signature at time X to the consumer or to a third party (timestamping service) which can witness that the signature existed at that time.

Blockchains can be used as a kind of distributed timestamping service, which might be useful when at time X the final data consumer isn't already known. Third-party timestamping services would serve the same function (they usually publish signatures of their logs for others to see, so that it can be proven that some timestamped signature must have been provided to them before the corresponding log signature).

1

One aspect of what you are looking for here is non-repudiation. Which is typically solved by digital signatures, as you suggest. The issue is that you would need to have the signature at time X in order to know that this was the same file.

To ensure the data has not been changed, if the data provider can send/broadcast a unique key and the signature to the consumer or there exists a trusted store of signatures and you can accept some small window of time from X to when it's recorded, that's a pretty straightforward solution.

It's the cryptographic hash that really proves the data has not changed. Calculating a hash of the data is part of validating the signature, but if need to store the hash in a secure manner to verify the content has not changed. A blockchain can be useful for preventing modification of history. At a high-level, it simply using the prior transactions as input to the hash on the next transaction. If you have a situation where the sequence of transactions are important and/or depend on each other, a blockchain might be worth exploring. Note: 'blockchain' here does not imply or require a decentralized blockchain such as used in Bitcoin.

The issue remains, though, that unless you can reliable know what the hash was at time X, you have no way of knowing when exactly each record was added to the chain. You can only know that ever was added to the change since you last looked at it has been added in between that time and now. So unless you (or a trusted third-party) have received the notification of the hash/signature at time X (with some delay tolerance), you cannot know when it was created.

There's another potential issue here that I see. All of this implies you know when X was. If you don't know when the data was created, it's possible for the provider to create it earlier and only sign it later and claim that was when it was created.

1
  • 1
    I somehow missed the X+10 aspect. More coffee apparently resolved my malfunction. Sorry for not addressing the full question initially.
    – JimmyJames
    May 2, 2022 at 17:07
1

You should take a look into RFC 3161 Time-Stamp Protocol:

A time-stamping service supports assertions of proof that a datum existed before a particular time.

Basically, on X, you hash your data, send the hash to a "Time Stamp Authority", and receive back a prove that the data existed. That "TSA" serves as a trusted source for time stamps.

Later, you may re-calculate the hash and validate it against the TSA's response. (To be honest, I never had to implement such solution, but saw it in the wild.)

Some articles describes it very well, e.g. https://www.metaspike.com/trusted-timestamping-rfc-3161-digital-forensics/

That article names Blockchain, too, but your problem is solvable without it.

0

For this to work you obviously need two bits of information. The timestamp of the version you have X and a list of any other versions between X and now.

If we assume a trusted exchange between the consumer and provider, you can simply ask the provider for the list.

Other solutions fail because your copy of the document with whatever hashes and timestamps wont change when a new version is created elsewhere in the world.

Not the answer you're looking for? Browse other questions tagged or ask your own question.