F

Press F for fullscreen

Preparing…

Graduation Project · 2026

ProofED

Decentralized digital verification of university certificates using Hashgraph technology

01 — The problem

The QR code proved the document.
Nothing proved the server.

TODAY

A QR code on the certificate

Universities in Gaza already embed one. It links to a verification page and it settles whether the paper in your hand was forged.

BUT

One server behind it

That page, that database, that institution. The whole chain of trust terminates at a single machine one organisation happens to run.

SO

One failure, everything gone

Downtime, compromise, or a department that stops paying the hosting bill — and every certificate ever issued becomes unverifiable.

The document was made tamper-evident. The verification path was not.
02 — Evidence

Single points of failure are not a thesis. They are a news cycle.

27 SEP 2025 · SOUTH KOREA
647

government services offline

A lithium-ion battery fire at the National Information Resources Service data centre took down the national mobile identification system with them.

20 OCT 2025 · AWS
us-east-1

region-wide outage

The best-resourced, most professionally managed infrastructure on earth, cascading anyway.

18 NOV 2025 · CLOUDFLARE
Global

platforms disrupted

A dependency so widely shared that its failure was indistinguishable, for many users, from the internet itself failing.

Every one of these was healthy, funded and well-run — right up until it was not.
03 — The idea

Anchor the proof, not the server.

SHA-256

Fingerprint

A fixed 256-bit digest of the exact bytes of the PDF. Change anything and it stops matching.

RSA-PSS

Signature

The university signs that digest with its private key. Authenticity, and non-repudiation.

IPFS

The file

Stored by content address, retrievable from any gateway rather than from one host.

HEDERA

The anchor

Hash, signature and CID written to a distributed ledger. No single operator can revise it.

Verification then asks the network, not the university. The institution can go dark and the certificate still proves itself.
04 — Objectives

Four goals. One system.

01

Secure certificate management

SHA-256 for integrity, RSA signatures under the university's private key for authenticity, and a tamper-evident record for every certificate issued.

02

Reliable verification

Public checking by QR scan or signature entry, internal search by student or national ID for authorised staff, with a real-time verdict.

03

Role-based access

A hierarchy of administrator, university staff and public verifier — with secure delegation, and system-level barriers to privilege escalation.

04

Portability

Decentralized storage, working QR codes, and certificates that stay verifiable independent of the issuing institution's operational status.

Secondary: a responsive interface across devices, and an architecture that extends as the population grows.
05 — System design

Four services. Clear boundaries.

Interface
Flutter WebIssuance and public verification, from one codebase that can compile to mobile later
Orchestration
Laravel 12 · PHPAuthentication, role-based access control, workflow orchestration, audit logs
Trust boundary — the private key never leaves here
Core · Python / FastAPISHA-256 hashing, RSA-PSS signing, IPFS upload
Bridge · Node.jsHedera Consensus Service, mirror node queries
External
Hedera HashgraphProof anchoring
IPFS · PinataCertificate files
MySQL / MariaDBRecords and metadata
Containerised with Docker · The Core module is isolated precisely so the signing key is never reachable from the web tier.
06 — Access control

Three roles, and nothing in between.

ADMIN

The university

Creates and revokes staff accounts, manages system settings, reads every audit log, revokes certificates. Strong authentication is the design recommendation for this role.

STAFF

The issuer

Uploads student certificates, supplies metadata, requests issuance on the university's behalf, generates QR and verification links, reads their own audit trail.

PUBLIC

The verifier

Unauthenticated. Can check a certificate by signature, CID or QR code. Can modify nothing — the read path needs no account, and is given none.

Sessions are JWT with device fingerprinting and a single-session policy; administrative actions require re-authentication.
07 — Workflow

Issuance: five deterministic stages.

Validate

Size and true file type

Hash

SHA-256, read in chunks

Sign

The university's private key

Store

IPFS, via Pinata pinning

Anchor

Hedera Consensus Service

Press Space to step through
A QR code is generated and embedded on the certificate. What is returned to Laravel: hash, signature, CID, gateway URL, transaction ID, topic ID.
08 — Workflow

Verification: two independent proofs, or nothing.

Present

Scan the QR, or paste the signature

Check signature

Cryptographic validity

Query the ledger

Hedera mirror node

Fetch

IPFS, if the bytes are wanted

Press Space to step through
VALID
Signature verifies and the ledger agrees. Either alone is not enough.
Two independent lines of evidence against forgery. A forger would have to break RSA and rewrite a distributed ledger.
09 — Why hashing works

There is no small tamper.

SHA-256 of the original
SHA-256 after changing one character
 
Computed live in this browser with crypto.subtle.digest — press Space to alter one character.
10 — The ledger choice

Why Hashgraph and not a blockchain.

Proof-of-work blockchainHedera Hashgraph
FinalityProbabilistic — wait for confirmationsDeterministic, in seconds
ConsensusMining racesGossip about gossip, then virtual voting
Cost per recordVariable, occasionally absurdFixed and predictable
EnergyProportional to securityNegligible
GovernanceDiffuseA known council of institutions
A certificate needs to be provably anchored at a known moment — deterministic finality is the whole requirement, and it is what a fee-predictable ledger buys.
11 — Scope

What was built, and what deliberately was not.

IN SCOPE

Delivered

The full certificate lifecycle for the University College of Applied Sciences: a Flutter Web platform for upload, issuance and public verification; a Laravel back-end for authentication, RBAC and orchestration; a Python/FastAPI Core for hashing and signing; a Node.js bridge to Hedera; IPFS storage with proof anchoring; QR and signature verification, plus internal search by student or national ID.

OUT OF SCOPE

Named, not hidden

Native iOS and Android applications — the Flutter choice keeps that door open. Dedicated key management (HSM or HashiCorp Vault); the signing key is a mounted PEM file in development. W3C Verifiable Credentials and DIDs. A bulk verification REST API for large institutional use.

Each exclusion is a decision with a reason, and each one reappears as future work.
12 — Honest limitations

Where this system is still standing on someone else's floor.

01

Third-party networks

Core function depends on Hedera and IPFS remaining available. Outages, protocol changes or fee changes on either would disrupt issuance or verification.

02

Private key storage

The university's signing key is a locally mounted PEM file on the Core service, so security is partly the hosting environment's access control.

03

No MFA

Administrator authentication is JWT with device fingerprinting and a single-session policy — strong, but not multi-factor.

04

IPFS persistence

Files stay available only while actively pinned. Content addressing guarantees identity, not permanence.

Stating these is not a weakness in the defence — it is the defence. An examiner will find them; better they are already on the slide.
13 — Future work

The next three moves.

SECURITY

Get the key off the filesystem

An HSM or HashiCorp Vault, for isolation, rotation and audit logging of key use. Then multi-factor authentication for administrators.

FEATURES

Mobile, standards, bulk

Compile the existing Flutter codebase to iOS and Android. Adopt W3C Verifiable Credentials and DIDs. Add a bulk verification API for institutional volume.

TESTING

Cover the two thin services

Testing concentrated on the back-end and front-end. The Core and Hedera Bridge services are the named gap, and the next thing to close.

Testing confirmed issuance and verification, session invalidation, device-context enforcement and administrator re-authentication.
Questions

Thank you

A certificate should outlive the server that issued it.

Abdelrahman M. Almajayda · Mustafa N. Shehab · Saleh A. Al-Kayyali  —  Questions welcome
1 / 15
move  ·  Space step  ·  Esc overview  ·  F fullscreen  ·  B blank