Digital signatures

This page is a capture in the next bucket of the product backlog — a pre-sprint idea, not yet pulled into a sprint as a story.

As suggested by gemini:

1. Digital Signatures (Non-Repudiation)

For high-stakes systems, you may want to store a cryptographic hash of the record.

When a Business Unit or Counterparty is updated, generate a hash of the new state.

Sign it with the user's certificate or a system-level key.

If an attacker (or a rogue DBA) tries to modify the temporal history directly in the database, the hash check will fail.

We need to be able to update the schema over time. However, one easy way this could be achieved is by saving a JSON blob with the row at the time of signing (ideally generated by a postgres function), sign that blob and record it. Then in the future we can make sure that those fields we recorded did not change at that version. This should be quite easy to implement. We could also take the git approach and create some kind of tree where all signed documents rely on previously signed documents, making it quite hard to tamper with the system.

Ideally when we create an account we need to associate keys with it.