Is there an accepted way to cryptographically enforce tracked changes on a document?

Question

I'm working on a document-editor project, and I would like to add a feature to lock tracked changes, similar to Microsoft Office. The goal is to allow one user to lock tracked changes with a password, which would allow other users to only edit the document with tracked changes. Any edit to the document that is not tracked would be detectable.

The solution I've come up with so far is to split the binary file into two sections: the original state of the file when tracked changes was turned on, and a list of the changes made since then. A checksum of the original file would be included and encrypted by the password provided. This would prevent other users from editing the block and producing a new checksum.

However, I believe that this would constitute a vulnerability because it would expose the password to a brute-force attack.

Is there any commonly accepted way to approach this problem, or any documentation on how other software (i.e. MS Office) solves this problem?

Thanks

Answer 1

A checksum of the original file would be included and encrypted by the password provided. This would prevent other users from editing the block and producing a new checksum.

This is a failed attempt to achieve integrity, with a secret password. A Message Authentication Code does that, with a secret key (see e.g. HMAC). One issue with the question's encrypted checksum is that for most document formats, it's easy to make two apparently identical documents with the same checksum. And even if we fix that by using a hash instead of a checksum, an encrypted hash is still not necessarily a proper MAC. That's because encryption is intended to provide confidentiality, not integrity. And for some common encryption systems (including the widely used and recognized AES-CTR), it's possible to alter the cryptogram obtained by encrypting a checksum/hash to match a different checksum/hash.

I believe that this would constitute a vulnerability because it would expose the password to a brute-force attack.

Yes, but there is a standard mitigation to this: using a purposely slow and salted Password-Based Key Derivation Function, such as Argon2 or scrypt, in order to generate the key of the MAC from the password (note: while PBKDF2 and it's ancestors are Password-Based Key Derivation Functions, they are obsolete, and do not seriously deter brute-force password search by powerful adversaries).

With the combination of a Password-Based Key Derivation Function and a MAC, there remains a devastating issue: the password or the key is needed to check the MAC, and that allows to forge a new MAC for a different text.

This issue is solved by using (public-key) digital signature instead of a MAC. Each user generates a public and a matching private key. The private key is necessary to make a signature, the public key allows to check it, and with that the integrity of the document, and which private key produced the signature. That could be extended to revisions (e.g. what's signed is the document as it stood when the user made the last revision. Multiple signatures of multiple states of the document can coexist, be stored in the document, and checked quickly enough).

A remaining problem is to distribute the public keys in a way ensuring their integrity and unique association to a user. One method is thru public key certificates.

Another remaining problem is storing the private keys in a manner ensuring confidentiality. That's usually done with encryption, and generating the encryption key with a Password-Based Key Derivation Function. That's standard with PGP/GPG private keyrings, and private keys matching public key certificates.

---

I would like to add a feature to lock tracked changes.
Is there any commonly accepted way to approach this problem?

Not much if you ask a cryptographer, beside

• The aforementioned use of digital signature with a trusted public repository of public keys, or public key certificates.
• Keeping the document on a trusted server keeping track of changes thru cryptographic authentication of users and user-originated changes, and defining the document as what's on this server; or a copy of that signed by the server.

And then the first option does not really prevents untracked changes, only bogus attribution of a change to a user that didn't originate it (assuming it's required that any change is signed). And in both options there remains the very real possibility that a user's computer is compromised, and changes to the document attributed to a user have been made contrary to the will of the user.

From a cryptographic standpoint, if one can read data using an untrusted computer, one can copy and alter it. The best crypto allows is detect that. This would be different if one assumed people can't modify what a program does. But that's not something crypto knows how to achieve on a standard, open computer.

Another option might be a blockchain. I don't really understand what that is or does (I recently asked), but can tell it does not qualify as widely accepted.

Answer 2

Based on the number of different demonstrated attacks on microsoft documents in the usenix paper

Office Document Security and Privacy by Müller et al,

available here I would say that what you want is probably impossible in a microsoft setting. You might want to track citations to that paper for possible related work in other environments.

Answer 3

The goal is to allow one user to lock tracked changes with a password, which would allow other users to only edit the document with tracked changes. Any edit to the document that is not tracked would be detectable.

These are two different goals. First is basically that the UI won't let the user disable the tracking changes feature, so they won't inadvertently disable that.¹ Second is that you want to detect if someone modified the document without tracking the changes.

The later is actually much simpler than what you are envisioning. You presumably had an original document, gathered input from many people, and now want to ensure the result is a faithful descendant of that document. You would simply have an option where you choose the parent document, and it tells you that all changes to the document are represented as tracked changes (i.e. the original state of both files is identical) or they aren't, showing an error message that there are untracked changes.

If you want finer accountability of the original and the changes, then you should go with digital signatures, such as adding pgp signatures to the original block and the different changes to the document (either individually or as by sets of changes).

¹ This can be a bad idea, though. I would actually prefer instead an approach making hard to disable it, such as showing multiple warnings of the being invalidated if they removed that. They shouldn't trust the tracking changes features, anyway. Worst case, someone could have retyped the whole document.