Where Should the Key That Signs the Audit Trail Live?

A signed audit trail is only as strong as the key that produces the signature. If the key sits in the wrong place the chain works flawlessly and proves nothing. This article is about where the key belongs and the three mistakes organisations typically make about it.

Why the Key Cannot Live in the Database

The assurance a signed chain gives comes down to one sentence: someone with full access to the database cannot recompute the chain. That sentence is true only when the key lives outside the database.

If the key is stored in a table, the person who wants to alter the chain is already there. Likewise, if the digest formula is written inside the database as a function or trigger, whoever can read the formula can run it again. In both cases you have a hash chain with no resistance to tampering at all.

The right place is the application's configuration layer: an environment variable, a configuration store protected at the operating system level, or a corporate key vault. The criterion is simple: nowhere a database administrator can reach with their ordinary privileges is suitable.

Two Different Keys, Two Different Jobs

A system that produces evidence holds two separate keys, and confusing them is a common design error.

• The audit chain key. Symmetric: signer and verifier hold the same key. It can therefore be given to nobody, not even the auditor. This is why chain verification runs from inside the product.
• The evidence package signing key. Asymmetric: the private half stays with the organisation, the public half goes into the package. The auditor checks the signature on their own machine and asks for no secret.

That split decides what the auditor can do independently. The product shows the chain is internally consistent; the auditor themselves shows the package has not changed and where it came from. A third check needs no key at all: comparing a value from a previously delivered anchor against today's record.

Who Should Be Able to Reach the Key

The answer is the smallest possible number of people, and those people should not be database administrators. The point is not to treat anyone as untrustworthy but to prevent an overlap of privileges.

If one person can both alter records and reach the key, the audit trail is not a control over that person. This is exactly the question an auditor asks: do those two privileges meet in one person?

In practice three separations help: the key with the server administrator, the data with the database administrator, and the right to produce evidence held by a third role under its own permission. In small teams the overlap may not be fully avoidable; the right response then is to accept it as a finding and define a compensating control. Delivering anchors outside is exactly such a compensating control.

Rotation: The Most Common Mistake

Key policies usually require periodic rotation. In an audit chain rotation carries a trap: once you change the key, older records were signed with the old key and cannot be verified with the new one.

The naive fix is to re sign old records with the new key, and that destroys the whole point of the chain: it turns the ability to recompute the past into an official procedure.

The correct answer is a key ring. Every record carries an identifier for the key that signed it. Signing always uses the active key, while verification can use any key in the ring. Old keys are not deleted, they simply stop being used for signing. The same pattern applies to evidence package signatures: a package produced after a rotation has to carry the keys older entries used, or those entries appear unverifiable.

If the Key Is Lost

This scenario surprises people because nobody discusses it. If the audit chain key is lost, records signed with it can never be verified again. The records remain readable and their content is not lost, but nobody can say any longer that they have not changed.

So a backup of the key belongs in the organisation's disaster recovery plan, and the backup itself is subject to access control. If it sits on a share everyone can reach, the key is not protected.

Anchors delivered outside act as a safety net here too. Even with the key lost, the digest of today's record can be compared against the old anchor the auditor holds. That comparison needs no key, so an organisation that lost its key can still show the past is intact.

A Checklist to Show the Auditor

With written answers to these six questions, key management will not produce a finding in an audit.

• Where is the key stored, and can a database administrator reach it?
• How many people can access it, and who are they?
• When and how will the key be rotated?
• After a rotation, how will older records be verified?
• Where is the backup of the key, and who can reach it?
• Is the person who can reach the key the same as the one who can alter records? If not, can the separation be demonstrated?

The last question is the most important and most organisations have no answer. If your answer is that they are separate, there should be a record showing it. That answer becomes evidence when the permission list is not a screenshot but a record whose changes are tracked.

Frequently Asked Questions

Should we give the audit chain key to the auditor?

No. That key is symmetric; anyone holding it can produce signatures. Handing it over would put the auditor in a position to produce records too, which breaks their independence. The independence they need comes from checks that require no key: the asymmetric signature on the evidence package and the comparison against a previously delivered anchor.

Do we have to use a corporate key vault?

Not necessarily. The criterion is not the brand of the tool but that the key sits somewhere the people with database access cannot reach. A configuration store protected at the operating system level achieves that. If you have a vault, using it is better; it brings access logging and rotation discipline with it.

Do old evidence files become invalid when the key changes?

Not if the key ring is set up correctly. Every record carries the identity of the key that signed it, and verification uses the matching key from the ring. A package produced after a rotation has to carry the public keys its older entries used; without them those entries appear unverifiable, which can look like tampering to an auditor.

Are server connection passwords protected with the same key?

No, and they should not be. Different jobs call for different key types. User passwords never need reversing, so they are hashed rather than encrypted. Server connection passwords have to be decrypted to be used, so they are encrypted in a mode that gives both confidentiality and integrity. The audit chain is signed with a keyed digest. Three jobs, three methods and separate keys.