Where Should the Key That Signs Evidence Live?

A signed evidence file is only as strong as the key that produced the signature. If the key sits in the wrong place, the signature works flawlessly and proves nothing. This article is about where the evidence signing key should live and the typical mistakes organisations make with it.

Why the Key Cannot Live in the Database

The assurance a signature gives can be put in one sentence: someone without the private key cannot alter a signed file and sign it again. That sentence is only true if the private key sits somewhere the people who can reach the records and files cannot.

If the key is kept in a table, the person who wants to change the record is already there. The right place is the application's configuration layer or the operating system's certificate store; a certificate store where the private key is marked non exportable is better still. The test is simple: nowhere a database administrator can reach with their ordinary rights is suitable.

Symmetric or Asymmetric

For evidence signing, the choice of key type decides what the auditor can do independently.

• A symmetric key (HMAC, for example). Signer and verifier hold the same key. So the key cannot be given to the auditor; verification can only happen inside the product, and the auditor has to trust what the product says.
• An asymmetric key (RSA, for example). 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 the organisation for no secret. In an installation with a signing key configured, SQL Change Guard signs evidence files, period packages and ledger digests with RSA; signing is switched on during installation, and without a key the packages are produced unsigned and the verification script says so explicitly.

A public key inside the package establishes no trust on its own: someone who puts their own key into the package also passes the signature check. So the organisation publishes the public key fingerprint somewhere independent of the packages (an internal portal, a signed letter) and the auditor compares the key in the package against that value. The records themselves rest on no key at all: they are protected by the engine in a SQL Server ledger table and verified with SQL Server's own procedure.

Who Should Be Able to Reach the Key

The answer is as few people as possible, and none of them the database administrator. The point is not to treat anyone as untrustworthy but to prevent privileges from overlapping.

If one person can both change records and reach the signing key, a signed file is no control against that person. That is exactly the auditor's question: do these two privileges meet in one person?

In practice three separations work: the key with the server administrator, the data with the database administrator, and the right to produce evidence with a third role under its own permission. In small teams the overlap may not be fully avoidable; then the right move is to accept it as a finding and define a compensating control. Writing the ledger digest to a store the database team cannot delete from is exactly such a compensating control.

Rotation: The Most Common Mistake

Key policies usually require periodic rotation. Evidence signing has a trap here: once you change the key, older files were signed with the old key and cannot be verified with the new one.

The naive fix is to re sign the old files with the new key, and that destroys the whole point of the signature: you have turned the ability to reseal the past into a corporate procedure.

The right fix is a key ring. Every file carries an identifier showing which key signed it. Signing always uses the active key, the public halves of older keys stay in the ring, and older files keep verifying against them. SQL Change Guard uses this pattern: the manifest names the identifier of the signing key.

If the Key Is Lost

With an asymmetric signature, losing the private key does not break the past: files signed earlier keep verifying as long as the public key is at hand. What is lost is the ability to sign anew; a new key is generated, its fingerprint is published again and signing continues with the new key.

The real danger is not loss but leakage. Someone who obtains the private key can produce files that appear signed by the organisation. That is why the backup of the key is under access control too, and on suspicion of a leak the key should be changed at once and the date up to which the old fingerprint was valid announced in writing. The integrity of the records is not affected; it rests on the ledger and the digests written out, not on the signature.

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 private key stored, and can a database administrator reach it?
• Where was the public key fingerprint published, independently of the packages?
• When and how will the key be rotated?
• After a rotation, how will older files 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 change records? If not, can the separation be shown?

The last question matters most, and most organisations have no answer. If your answer is "no, they are separate", there should be a record showing it. When the permission list is a tracked record rather than a screenshot, that answer becomes evidence.

Frequently Asked Questions

Which key should we give the auditor?

Only the public key and its fingerprint. The private key goes to no one. The auditor's independence comes from verifying signatures with the public key and from verifying the SQL Server ledger with its own procedure; neither needs the private key.

Do we have to use a corporate key vault?

No. The test is not the brand of the tool but whether the key sits somewhere people with database access cannot reach. The operating system's certificate store also meets that. If you have a vault, using it is of course 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 properly. Every file carries which key signed it, and verification uses that key's public half. Old public keys and their fingerprints should be kept.

Are server connection passwords protected with the same key?

No, and they should not be. Different jobs need different key types. User passwords never need to be reversed, 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. Evidence files are signed with an asymmetric key. Three jobs, three methods and separate keys.