1

I am aware that it is possible to use a block cipher with the GCM-mode to provide authenticity, but this does not completely do what I need.

I have a cloud storage provider I do not completely trust, in particular when it comes to rolling back the data. I use AES-GCM to encrypt and authenticate the data, but what prevents the server from rolling the file back to a previous version? As far as I understand this would still decrypt without any issues because the old auth tag matches with the old encrypted data?

I read the answer to another question here, but in the first part of the answer kelalaka mentioned 4 bullet points that he marked as "not helping" and in the second part of the answer there is still some state required on the client to detect anything.

What can I use to detect, at least as a human, that the data was rolled back? I thought about using Hash-Trees, as per the answer to the question above, (with HMACs instead of hashes alone) and add the timestamp from the latest changes to the HMAC of the root directory. This way the client application could check if the timestamp matches with the root HMAC and the user can see if the retrieved timestamp (displayed as a date) makes sense. Also, when the application was used on the client previously, the application could detect the rollback when the timestamp is smaller than the one that was retrieved in the latest valid retrieval.

Would this be a feasible extension to the answer kelalaka mentioned? When updating it is sufficient to renew the hmacs from the file to the root, which does not seem to bad, and when retrieving the data a human can check roughly if the data is up-to-date.

1
  • This might be out of scope, but this problem may be solvable using a blockchain. After making a change to the data, the client calculates the root HMAC of the data and stores this value in the blockchain (e.g. in the op_return field of a bitcoin transaction). A malicious actor is unable to change this value, due to the immutable nature of blockchains. This also alleviates the need for the client to store the root HMAC. To verify that the data has not been rolled back, the client calculates the current HMAC root of the data, and verifies that it matches the HMAC root stored in the blockchain.
    – mti2935
    Jul 24 at 14:00
1

As far as I understand this would still decrypt without any issues because the old auth tag matches with the old encrypted data?

Right

Your approach would generally work. However, I find a bit odd your description of adding "the timestamp from the latest changes to the HMAC of the root directory". I'm not sure if you mean into, or just the . If the root directory contain the hash/HMAC of the file, then you can detect the rolling back of that file. No need to check the file timestamps at all (you could store this last update metadata either with the file itself, or in the directory entry). It is enough for you to store the last change timestamp to the "cloud filesystem" in that root directory, so that you can show to the user the version they are browsing (and detect rollbacks).

I would recommend to store a sequential id as well. While the actual timestamp would work reasonably well for people, the application checking it is not being given a rollbacked view would work best with monotonically increasing ids (e.g. suppose that there are two updates in the same second).

Also, you need to be careful to ensure your update to the root directory (or other intermediate directories) cannot be mixed with two clients changing files at the same time and overwriting an older version (you could use atomic updates of the blob, checking the prior contents are those it knew about).


PS: I disagree with @mti2935 'blockchain solution'. Any secure communication channel would be enough to detect the rollback. Sure, you could do this in a cryptocurrency blockchain, but that's completely overkill. And certainly not "easier" than doing so in the client app, which would be free. Simply a server in a different provider, albeit with less space could serve as notary of the cloud provider. Or even a service like twitter.

2
  • yes, I agree that this would work, but it is vulnerable to the cloud storage provider and the other provider colluding. I'm not sure if OP trusts the storage provider and the other provider not to collude (that's why I said this might be out of scope), but I threw out the blockchain solution because it is trustless and does not require the client to store any state information.
    – mti2935
    Jul 25 at 1:14
  • Yeah, the sequential counter would be a good idea to make it easier for computers, especially because the clocks might not be synchronized across multiple devices. I meant to say 'into the hmac'. I think what you mean with 'It is enough for you to store the last change timestamp to the "cloud filesystem" in that root directory' is the same of what I mean with adding the timestamp of the latest change into the hmac of the root directory, and also in plain for verificatoon), is it not? A Blockchain is definitely not what I am looking for, no data on the activity of a user should be made public.
    – Gamer2015
    Jul 25 at 17:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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