Blockchain security includes protecting exchanges, wallets, and smart contracts, but also using blockchain to check whether documents have changed.
Sensitive originals such as security audit materials are encrypted and kept private, with only file hashes, or digital fingerprints, recorded in an independent ledger. Later recipients can recalculate the hash and compare it with the recorded value (p.13).
As AI makes plausible documents and identities easier to create, verifying their origins and whether they have changed becomes more costly (p.38). The contribution therefore proposes protecting originals while retaining hashes, issuer signatures, and verification histories (p.13-14).
This approach proves whether a record has changed since recording. Whether its contents are true requires separate judgment (p.15).
The earlier article on smart contract hacking examined vulnerabilities in code on a blockchain; this article examines what blockchain can protect.
What does a hash verify in a document?
A hash is the result of converting a file into a unique, fixed-length value. Even a very small change in a document produces a completely different value.
If the original hash is recorded on a blockchain, anyone with the file can recalculate its hash and compare it with the recorded value. Only the fingerprint goes onto the ledger, so sensitive originals never leave private storage (p.13).
Tamper evidence is more precise than immutability
The US National Institute of Standards and Technology (NIST) describes blockchain as a tamper-evident and tamper-resistant distributed ledger, rather than a literally immutable one. As blocks accumulate, changing the history becomes harder, and changes become visible (p.13). Blockchain security rests on making changes evident, rather than absolute safety.
Verification gaps left by PDF reports
Security assurance still mostly ends with PDF documents. Customers receiving reports months later have difficulty independently checking whether a file is original, its supporting evidence has changed, the signer was authorized, or a certification remains valid (p.13).
This is the gap blockchain security seeks to fill. The following compares two approaches to a penetration testing report (p.14 Figure 1).
| Step | A. Delivering PDF copies | B. A verifiable history |
|---|---|---|
| 1 | Consultant sends a PDF | Report is issued and digitally signed by its issuer |
| 2 | Company stores the PDF | Hash is created and recorded in a ledger |
| 3 | Auditor reviews the PDF | Auditor verifies and signs the evidence |
| 4 | Customer receives another copy | Assurance report points to verified evidence |
| Result | Copies may lack a technical connection | Records who verified which version and when |
Under approach B, uploading a different report with the same file name produces a hash mismatch. The history also records which version an auditor relied on, certification expiry, and evidence replacement (p.14).
How blockchain security technology is structured
The proposal is to add an independently verifiable proof layer above private evidence systems, rather than put audits on a blockchain (p.14). In June 2026, the IETF also standardized an architecture for registering signed statements and receiving cryptographic receipts in RFC 9943 (p.14).
| Component | Function |
|---|---|
| Off-chain evidence | Originals are encrypted and stored separately; only hashes, evidence IDs, and timestamps go on the ledger |
| Origin signatures | Hashes show only whether something changed; digital signatures establish who created it |
| Lifecycle records | Record creation, approval, replacement, expiry, and revocation as events that cannot be altered secretly |
| Verifiable credentials | W3C standard; credentials software can verify directly without asking the issuer |
| Zero-knowledge proofs | Verify that conditions are met without disclosing originals; ISO/IEC 27565:2026 guidance |
Reports can remain as they are. They are simply no longer the sole basis recipients must trust (p.15).
Three things blockchain cannot prove
1. Fabricated evidence is also preserved unchanged Recording the hash of a fabricated document proves only that it was recorded then and has not changed since. Auditors determine whether evidence is sufficient and appropriate (p.15).
2. Not every problem needs a blockchain Digital signatures, trusted timestamps, and transparency logs provide much of the same functionality. Blockchain is useful when several institutions need to verify a shared history without giving any one institution control (p.15).
3. It cannot establish the truth of inputs outside the ledger Blockchain makes records difficult to alter, but cannot prove that outside inputs were true or actions were authorized. A lasting record of a bad decision remains a bad decision (p.31).
Supplier evidence and trust in the AI era
Supplier security also includes proposals to replace annual questionnaires with tracking who supplied evidence, which version was reviewed, and whether it subsequently changed. Evidence true at review is not guaranteed to remain true (p.21).
As AI makes intelligence abundant, trust becomes scarce. Identity and credential infrastructure answering who created something and who authorized a machine to act could be blockchain's next use (p.38-39). This is blockchain security centred on proof rather than coins.
Frequently asked questions
Q1. Does putting something on a blockchain prevent hacking?
No. Blockchain makes records difficult to alter but does not protect an entire service from hacking. If fabricated material is uploaded at the outset, it too is preserved unchanged (p.15, p.31).
Q2. What is a zero-knowledge proof?
It is a cryptographic technique for verifying that conditions are met without disclosing the original material. Proving that all employees completed background checks would no longer require disclosing an entire payroll file (p.15).
Q3. How do hashes and digital signatures differ?
A hash verifies whether a file has changed, while a digital signature verifies who issued it. That is why they are used together (p.14).
At a glance
- Blockchain security also supports verification of change histories
- Keep originals private; record hashes, signatures, and verification histories in the ledger
- Whether something changed and whether it is true are separate questions
- Blockchain adds a proof layer to assurance (p.15)
When evaluating blockchain security technology or receiving a document stating that something was verified, first ask what was checked, which version, by whom, and when (p.15).
Read the full KCBCA Signals Vol.1 Issue 1
References: KCBCA Signals Vol.1 Issue 1; Anthony Green (Managing Partner, Greenhat Assurance; Director, KCBCA GLOBAL) p.13-15; Rob Goehring (CEO, Wisr.ai) p.21; Ted Kim (CEO, Shorti) p.31; Aelia Zawiłska (Founder, RAEYS) p.38-39
