Hall-Ticket and Marksheet Hash Registry with Offline QR Verification for a College Exam Branch

Examination fraud starts with a printer. A hall ticket with a swapped photograph, a forged arrears-cleared marksheet, a doctored transfer certificate — documents an autonomous college issues in thousands each semester are exactly the ones an employer, another university or an invigilator in a connectivity-dead exam hall cannot check quickly.

VeriSheet is a credential hash registry for the exam branch of a fictional autonomous college (Kaveri College of Arts and Science, Erode), built on blockchain's core construction — hash chaining and Merkle trees — without tokens or strangers. The branch uploads each sitting's batch as CSV; the system canonicalises every record (hall ticket, marksheet, transfer certificate), computes its SHA-256 fingerprint, and seals the batch as a block whose Merkle root chains to the previous block — a college-signed ledger of which credentials existed and when. Each printed PDF carries a QR code encoding the serial number and the full hash.

Online, an employer or help desk enters the serial or scans the QR and sees the registry record beside a chain-integrity badge. Offline, before each sitting the branch exports a digitally signed snapshot (Ed25519) of the serial-to-hash table and revocation list to invigilator devices; a network-dead hall still recomputes the hash, checks membership and the snapshot signature, and flags tampering with paper or snapshot. Intermediate in scope, it still exercises genuine cryptography — canonicalisation, Merkle proofs, key management, revocation — each demonstrated against a live tamper test.

A college exam branch issues thousands of hall tickets, marksheets and transfer certificates each semester, yet a printed credential carries no checkable evidence that it matches what the branch actually issued. Photograph swaps, edited arrears columns and reused serial numbers are discovered only when someone telephones the branch — days later, or never. In exam halls, invigilators often have no connectivity at all, so even a web lookup is impossible at the moment of doubt. There is a need for a registry that fingerprints every credential at issuance (SHA-256 over a canonicalised record), anchors those fingerprints in a tamper-evident, college-signed hash chain, prints each credential with its own QR-encoded fingerprint, supports verification without internet through a signed snapshot and revocation list on invigilator devices, and records every verification attempt for audit — while storing no government identity numbers.

Abstract

This project builds VeriSheet, a hash-anchored credential registry for a college exam branch. Each credential record is canonicalised and fingerprinted with SHA-256; per-sitting blocks carry Merkle roots chained to the previous block, with the tip signed by the college's Ed25519 key. Printed PDFs carry QR codes holding the serial number and hash. Verification runs online against the registry and offline from a signed snapshot with revocation list, so invigilators verify credentials in a network-dead hall. Tampering with the registry, a snapshot or printed credential is caught by recomputation; no government identity numbers are stored.

Introduction

An autonomous college issues credentials constantly — roughly 4,800 hall tickets a semester, marksheets on demand, transfer certificates for leavers. Each is trusted on sight; verification requests travel back to the branch by phone. The branch is honest, but the paper leaves its control at the printer. The branch is a single issuing authority, so a hash-anchored, self-verifying registry fits without consensus machinery: blockchain's evidence structure, right-sized.

Existing System and Its Limitations

• Credentials are printed and trusted on sight; no independent check exists that a paper matches what was issued.
• Verification is manual: a phone call, a register search, days of delay.
• Forgeries exploit exactly this gap — photograph swaps, edited arrears columns, reused serial numbers.
• Limitations: no fingerprint per document, no tamper evidence, no offline check, no revocation.

Proposed System

• Canonical fingerprinting: each record is serialised to canonical JSON (sorted keys, fixed dates) and hashed with SHA-256; the registry stores the hash, not the document.
• Chained blocks per sitting: each sitting's batch forms a block with a Merkle root over its credential hashes; blocks chain to the previous root and the tip is Ed25519-signed.
• QR-carrying PDFs: printed credentials carry a QR encoding serial number and full hash — the paper carries its own fingerprint.
• Online verification: a public page recomputes, compares and logs every attempt beside a chain-integrity badge.
• Offline verification: before a sitting, the branch exports a signed snapshot (serial→hash table, roots, revocation list) to invigilator devices; the offline verifier checks signature, membership, hash equality and revocation — no internet.
• Revocation: cancelled credentials enter a signed revocation list shipped with every new snapshot; revoked serials fail loudly.

Feasibility Study

• Technical: node:crypto provides SHA-256 and Ed25519; MongoDB holds registry and audit documents; qrcode and PDFKit generate the artifacts; a 5,000-credential snapshot is ~160 KB, trivially distributable to phones; Docker Compose makes the demo self-contained.
• Economic: zero licence cost; the branch already owns a PC, printer and PDF workflow.
• Operational: the branch uploads CSV exactly as today; invigilators need a one-page sheet; verification takes seconds. Seed data: 1,200 hall tickets, 300 marksheets, one revoked serial, one tampered snapshot.
• Context: DigiLocker shows the national direction; this project serves the college-local paper workflow those platforms do not reach, and stores no Aadhaar, PAN or identity numbers.

In scope

• One autonomous college's exam branch: two roles (exam-branch officer, invigilator/verifier) plus a public verification page; one seeded semester of credentials.
• Batch intake by CSV, canonical fingerprinting, chained per-sitting blocks, Merkle roots, signed snapshots, offline verification, signed revocation, PDF/QR rendering and the verification audit trail.

Out of scope (v1)

• Integration with university results portals, DigiLocker or NAD/DigiLocker-style national APIs — the registry is college-local and self-contained.
• Marks processing itself: the branch's existing exam software remains the source of the CSV; VeriSheet fingerprints and verifies, it does not compute results.
• Public-blockchain anchoring or consensus among colleges (future work); membership here is one issuing authority.
• Biometric identity checks at the hall and storage of any government identity numbers — students are referenced by register number and serial only; photographs are stored as hashes, not images, in the registry.

The project follows an incremental SDLC over 14 weeks with a working demo at every stage, appropriate for a single-author Anna University R2021 Semester-4 consolidated project. The cryptographic core (canonicalisation, hashing, chain) is built and tested before any UI.

Testing approach: golden-vector tests pin the canonicalisation (key order, Unicode names, date formats) against hand-computed SHA-256 values; chain tests recompute Merkle roots and verify signatures; tamper tests mutate a registry document, a snapshot byte and a canonical field to assert detection with the failing item named; Supertest covers the API; and an offline-device test verifies a snapshot on a phone with airplane mode on.

VeriSheet is a three-tier application with a cryptographic core.

1. Presentation tier: the exam-branch console (React) for batch upload, block inspection and snapshot export; the public verification page; and the offline verifier page served to invigilator devices.
2. Application tier: Express services — intake and canonicalisation, chain management, PDF/QR rendering, verification (online and offline), revocation and key management. Every signature operation happens server-side; keys never reach the browser.
3. Data tier: MongoDB holds credential documents (canonical record, hash, serial, sitting, status), block documents (Merkle root, previous root, signature) and the verification audit log. The chain-tip signature and exported snapshots are stored as files outside the database.

flowchart TD
  EB(["Exam branch officer"]) -->|"CSV batch upload"| INT["Intake: canonical JSON + SHA-256"]
  INT --> REG[("MongoDB: credential records")]
  REG --> BLK["Block builder: Merkle root per sitting"]
  BLK --> CH[("Chain: root ← previous root; tip signed Ed25519")]
  CH --> PDF["PDFKit + qrcode: serial + hash in QR"]
  PDF --> PR(["Printed hall tickets / marksheets"])
  VU(["Employer / verifier (online)"]) -->|"serial or QR scan"| OV["Online verifier: recompute + compare + badge"]
  OV --> REG
  OV --> AUD[("Verification audit log")]
  CH --> SNAP["Snapshot builder: serial→hash table + roots + revocation, signed"]
  SNAP --> DEV(["Invigilator device (offline)"])
  IV(["Invigilator (exam hall)"]) --> OFF["Offline verifier: signature + membership + hash + revocation"]
  SNAP --> OFF
  KMS["Key ceremony: college Ed25519 keypair"] --> CH
  KMS --> SNAP

Registry data model

erDiagram
  SITTING ||--o{ CREDENTIAL : contains
  SITTING ||--|| BLOCK : "is sealed as"
  BLOCK ||--o{ CREDENTIAL_HASH : "covers via Merkle"
  BLOCK }o--|| BLOCK : "chains to previous root"
  CREDENTIAL ||--o| REVOCATION : "may be revoked"
  CREDENTIAL ||--o{ VERIFICATION : "is checked in"

  SITTING {
    string sitting_id PK
    string semester
    date exam_start
    int credential_count
  }
  CREDENTIAL {
    string serial PK
    string sitting_id FK
    string type
    string register_no
    string canonical_json
    string sha256
    string status
  }
  BLOCK {
    int height PK
    string merkle_root
    string prev_root
    string tip_signature
    datetime sealed_at
  }
  REVOCATION {
    string serial PK
    string reason
    datetime revoked_at
  }
  VERIFICATION {
    string id PK
    string serial FK
    string mode
    string result
    datetime checked_at
  }

Verification flow (online and offline)

flowchart TD
  IN(["Credential presented"]) --> S1["Read serial + hash from QR / form"]
  S1 --> S2{"Mode?"}
  S2 -->|"online"| O1["Fetch record; recompute SHA-256 of canonical JSON"]
  O1 --> O2{"Hash matches and chain valid?"}
  S2 -->|"offline"| F1["Load signed snapshot; verify Ed25519 signature"]
  F1 --> F2{"Serial present and hash equal?"}
  F2 -->|"no"| R1["FLAG: not issued / altered"]
  O2 -->|"no"| R1
  O2 -->|"yes"| RV{"Revoked?"}
  F2 -->|"yes"| RV
  RV -->|"yes"| R2["FLAG: revoked — show reason"]
  RV -->|"no"| OK["VERIFIED — show record summary"]
  R1 --> AUD[("Audit log")]
  R2 --> AUD
  OK --> AUD

The registry stores canonical records and hashes — names, register numbers, subject codes — but no photograph images and no government identity numbers; the photograph's SHA-256 is stored so a swapped photo breaks the fingerprint while the image itself stays in the branch's own system.

• Public-blockchain anchoring: publish each sitting's Merkle root to a public chain or timestamping service so even the college cannot silently rewrite history.
• Multi-college federation: colleges cross-verify each other's signed roots through a lightweight consortium chain — the natural consensus step when there is more than one authority.
• Camera-based hall checking: the invigilator photographs the hall ticket; on-device QR decode and hash check remove typing entirely.
• Employer verification portal with per-request tokens, so a verification can be tied to a consented request rather than an open lookup.
• DigiLocker-style issuer API for digital-first issuance alongside paper, with the same registry underneath.
• Analytics: mismatch-attempt patterns by serial range or timing as an early-warning signal for organised forgery.