Can Blockchain Fix Identity Theft? My MCA Final Year Project Says Maybe
My MCA Final Year Project — I Built a Blockchain Identity System That Solves a Real Cybersecurity Problem
Every cybersecurity problem I've studied over the past year — data breaches, identity theft, Aadhaar fraud, social engineering scams — points back to the same architectural weakness: centralised identity systems that store sensitive data in one place, require you to over-share personal information just to prove something simple, and give you zero control over who has access to what.
For my MCA final year capstone project at PES University, I decided to build something that addresses this problem directly. DIAM — Decentralized Identity and Access Management — is a blockchain-based identity system that gives users cryptographic control over their credentials, enables selective disclosure through Zero Knowledge Proofs, and anchors verification data on the Ethereum blockchain so credentials cannot be forged.
This post is the story of building it: why I chose this problem, the security architecture behind the solution, the specific cybersecurity concepts the system implements, and what six months of building a real security system taught me that no lab, certification, or blog post could.
DIAM — Project At a Glance
- Why I chose this problem — the real security failures that motivated DIAM
- The core problem: why centralised identity is a security disaster
- The security architecture — every concept explained
- Zero Knowledge Proofs — the hardest and most interesting part
- Smart contracts in Solidity — what they do and why they matter
- System architecture and what I built
- Test results — 14 test cases, all passing
- What building this taught me that studying security didn't
Why I Chose This Problem
I chose the DIAM problem for two reasons that converged in the same week in January 2026.
The first: I had just been targeted by a social engineering scam — a fake recruiter on LinkedIn who, after two weeks of a convincing interview process, asked for my Aadhaar card and a selfie for "KYC verification." I wrote about it on this blog. What struck me afterward was not just the social engineering technique, but what the attacker intended to do with my Aadhaar data: open fraudulent accounts, take loans, register SIM cards. The entire fraud depends on the fact that Aadhaar verification requires you to hand over your full biometric identity data to prove something simple — like that you're an adult, or that you're a student.
The second: I was studying access control in my TryHackMe labs and reading about how most data breaches begin — through compromised identity systems where user credentials are stored centrally. One server gets breached, millions of records exposed. The architectural problem is the centralisation itself.
DIAM addresses both: a system where you can prove things about yourself (I am an adult, I am a verified student, I am a government employee) without handing over the underlying documents to each verifier. Where credentials are cryptographically signed and blockchain-anchored so they can't be forged. Where you control exactly what's shared and with whom.
That felt like a cybersecurity problem worth solving — or at least, worth building a working prototype of.
The Core Problem: Why Centralised Identity Is a Security Disaster
Before explaining what DIAM does, it's worth being precise about why the existing systems are architecturally broken from a security perspective. This matters for understanding why the design decisions I made were made.
Single Point of Failure — One Breach Exposes Everyone
Traditional identity systems store all user credentials in a centralised database. This creates a single, high-value target. The Aadhaar system, OAuth providers like Google and Facebook, enterprise Active Directory installations — all of these are centralised. A single successful breach of the server exposes the identity data of every user in the system simultaneously.
This is not a theoretical risk. The 2018 Aadhaar data breach exposed over 1 billion records. Major OAuth providers have been breached. Enterprise Active Directory compromise is one of the most common attack vectors in ransomware incidents.
Over-Collection — You Share Everything to Prove One Thing
When you verify your age to buy a restricted product, you show your entire ID card — date of birth, address, photo, ID number, everything — to prove one bit of information: you are over 18. When you submit documents to a new employer, you give them your full educational certificates when they only need to verify you have a degree. Every verification interaction collects more data than necessary.
This over-collection creates two problems: it exposes data to verifiers who don't need it and may not secure it properly, and it creates honeypots of sensitive data at every organisation that has verified users.
No User Control — You Can't See Who Has Your Data or Revoke Access
With centralised identity, once you've submitted your documents to a service, you have no visibility into how they're stored, who has access, or how to revoke that access. Your data may be shared with third parties without your knowledge. You have no consent mechanism and no audit trail of who accessed your credentials.
Document Forgery — No Cryptographic Verification
Traditional paper credentials and even most digital credentials can be forged. A PDF certificate can be modified. A scanned ID can be edited. Without cryptographic signing tied to the issuing authority, a verifier has no way to confirm a credential is genuine without contacting the issuing institution directly — which is slow, expensive, and doesn't scale.
The Security Architecture — Every Concept Explained
DIAM implements several advanced security concepts. I want to explain each one clearly — both what it is and how I actually implemented it — because these are the concepts this blog covers from a theory perspective, and building them gave me a completely different level of understanding.
Decentralised Identifiers (DIDs)
IdentityA Decentralised Identifier is a globally unique identifier that doesn't require a central registrar — no Google, no government database, no company — to issue or validate it. A DID looks like this: did:diam:123abc. It's cryptographically generated from a key pair, so only the person who holds the private key can prove they own that identifier.
In DIAM, when a user registers, the system generates a cryptographic key pair. The public key becomes the basis for their DID. The DID is stored in MongoDB along with the public key. The private key stays with the user. No central authority assigned them this identity — they own it cryptographically.
Verifiable Credentials (VCs) and Digital Signatures
CryptographyA Verifiable Credential is a cryptographically signed digital document that proves a claim about a subject. An authority (university, government department, hospital) issues a VC to a user's DID, signing it with their private key. The credential contains: who issued it, who holds it, what it claims, when it expires, and a digital signature that proves it hasn't been tampered with.
When a verifier receives a VC, they can verify: (1) the digital signature matches the claimed issuer's public key, (2) the credential hash matches the blockchain record, (3) the credential hasn't been revoked. No contact with the issuer is needed.
Ethereum Blockchain and Smart Contracts
BlockchainThe Ethereum Sepolia testnet is DIAM's trust anchor — the immutable record that makes credential verification trustworthy. Here's the key architectural decision: personal data never touches the blockchain. Only cryptographic hashes of credentials and revocation events are stored on-chain. This means a blockchain breach would reveal nothing about user identities — only that certain hashed values were anchored at certain times.
Smart contracts in Solidity handle: credential hash anchoring, issuer registration in a trust registry, revocation events, and the audit log. A smart contract is code that runs on the blockchain itself — it executes exactly as written, cannot be modified after deployment, and its execution is verifiable by anyone.
Zero Knowledge Proofs — The Most Interesting Security Concept
PrivacyA Zero Knowledge Proof (ZKP) is a cryptographic method that allows one party to prove they know something — or that a statement is true — without revealing the underlying information. The classic example: proving you know a password without transmitting the password itself.
In DIAM, ZKPs enable selective disclosure. Consider age verification. A nightclub wants to verify you're over 18. With a traditional ID, you show your entire ID card — date of birth, address, photo, ID number. With a ZKP-based system, you generate a cryptographic proof that your date of birth is before a certain date, without revealing the actual date. The verifier can confirm the proof is valid without learning when you were born.
Consent-Driven Access Control
IAMEvery access control textbook covers the principle of least privilege — giving each entity access to exactly what it needs, nothing more. DIAM implements this at the user level through a consent dashboard. When a verifier requests access to a credential, the request is routed to the user's dashboard. The user sees: who is requesting, what credential they're requesting, and why. The user must actively approve before the verifier sees anything.
This is the identity equivalent of OAuth's permission screens — but with cryptographic enforcement rather than just UI design. Every consent decision is logged with a timestamp and blockchain transaction hash, creating an auditable trail of every access event.
System Architecture — What I Actually Built
Role-based dashboards
User / Authority / Verifier / Admin
Authentication
Business logic
Encrypted credentials
User DIDs
Solidity contracts
Hashes only
Four dashboards, each with role-specific functionality:
- User Dashboard: View all credentials (Aadhaar, PAN, Driving License visible in the screenshots), check credential status (active/expired/revoked), share credentials with consent, monitor verification requests
- Authority Dashboard: Issue new credentials to users, manage issued credential lifecycle, handle pending requests, revoke credentials with blockchain update
- Verifier Dashboard: Request credential verification via QR scan, file upload, or manual credential ID, view verification history with blockchain confirmation status
- Admin Dashboard: Manage all users and roles, configure system settings, view system-wide audit logs
Test Results — All 14 Test Cases Passed
I built 14 manual test cases covering the full system lifecycle. Every single one passed. Here are the ones most relevant to the security architecture:
| Test Case | What It Tests | Result |
|---|---|---|
| TC002 — DID Generation | DID generated in correct format, unique for user, blockchain transaction confirmed | ✓ Pass |
| TC003 — Credential Issuance | Digital signing, blockchain anchoring, user notification — all correct | ✓ Pass |
| TC006 — Consent Approval | User consent flow — approval triggers blockchain transaction, verifier notified | ✓ Pass |
| TC007 — Blockchain Verification | Credential hash matches blockchain, signature valid, status confirmed | ✓ Pass |
| TC008 — Credential Revocation | Revocation recorded on blockchain; subsequent verifications return "revoked" | ✓ Pass |
| TC011 — ZKP Age Verification | Age proved without revealing date of birth — proof validates, data hidden | ✓ Pass |
| TC012 — Multi-Authority Validation | Government, university, and hospital credentials validated independently | ✓ Pass |
| TC014 — Concurrent Consent | Multiple simultaneous consent requests processed without conflicts | ✓ Pass |
What Building This Taught Me That Studying Security Didn't
Six Months of Building vs Reading — What's Different
- Security is a design problem, not a feature: You cannot add security to a system after building it. Every architectural decision in DIAM — off-chain storage of personal data, on-chain anchoring of hashes only, consent-required access — is a security decision made at the design stage. Trying to retrofit these would require rebuilding the system. This is the insight that security architecture courses try to teach; building a real system made it visceral.
- Cryptography is harder to implement correctly than to understand conceptually: I understood digital signatures theoretically from my PortSwigger labs and CompTIA Security+ study. Implementing them — getting the hash function right, ensuring the signature verification covers exactly the right data, handling key storage securely — exposed every gap between conceptual understanding and correct implementation. The bugs weren't in the concepts; they were in the implementation details.
- Smart contracts make you think about security in new ways: Code deployed on a blockchain cannot be patched after deployment. Every vulnerability is permanent. Writing Solidity forced me to think about reentrancy attacks, integer overflow, access control in a way that you only do when mistakes are genuinely irreversible. I tested every function against common Solidity vulnerabilities before deployment.
- The hardest security problems are social, not technical: The technical architecture of DIAM is sound. The harder problem is: how do you get authorities to adopt this system? How do you migrate people from centralised identity habits? How do you handle key loss — if a user loses their private key, they lose their DID? These questions have no elegant cryptographic answers. They're social and institutional problems, which is humbling after spending months on elegant technical solutions.
- Zero Knowledge Proofs are genuinely difficult to implement correctly: Understanding ZKPs conceptually — you can prove knowledge without revealing what you know — took a few hours of reading. Implementing a correct ZKP that doesn't leak information through side channels, produces verifiable proofs, and handles edge cases correctly took weeks. The gap between concept and correct implementation is enormous in cryptography.
How DIAM Connects to Everything on This Blog
Looking at what DIAM implements against what I've been studying and writing about for the past year, the connections are direct:
- Identity and Access Management — the core subject of DIAM maps directly to CompTIA Security+ Domain 4, which I studied and wrote about. Building a real IAM system gave me a depth of understanding that studying for the exam alone didn't.
- Cryptography — digital signatures, hashing (keccak256), key generation, and ZKPs are all concepts from the Security+ Domain 1 cryptography section. Implementing them in Solidity and Ethers.js made them non-abstract.
- The scam attempt I wrote about — the fake recruiter asking for Aadhaar KYC is exactly the attack vector DIAM prevents. If Aadhaar used a DID-based model with consent-driven verification, a scammer who says "send me your Aadhaar for KYC" would receive only a cryptographic proof that you are who you claim to be — not your full identity document.
- Blockchain security — smart contract vulnerabilities (reentrancy, access control, integer overflow) are real attack surfaces. The DIAM contract is simple enough to avoid most of them, but designing around them required understanding how they work — which connects to the vulnerability research this blog covers.
- Zero Trust Architecture — DIAM implements the Zero Trust principle of "never trust, always verify" at the identity layer. No credential is trusted because an authority issued it; every credential is verified cryptographically against the blockchain before acceptance.
Key management for non-technical users. The system's security relies on users protecting their private keys. If a user loses their private key, they lose control of their DID. For the billions of people who struggle with passwords, managing cryptographic keys is a significant barrier. Future work: hardware security keys and recovery mechanisms.
Ethereum testnet, not mainnet. DIAM runs on the Sepolia testnet — test ETH, not real ETH. Deploying to mainnet would cost real money in gas fees for every credential anchoring transaction. Production-scale deployment would require either Layer 2 solutions to reduce gas costs, or a different blockchain approach (Hyperledger Fabric for a permissioned network).
The ZKP implementation is simplified. The full mathematical ZKP — using ZK-SNARKs or ZK-STARKs as used in production systems like Zcash or Polygon's zkEVM — is significantly more complex than what's implemented in DIAM. My implementation demonstrates the principle of selective disclosure; a production ZKP system is an active research area.
Being honest about what a prototype doesn't do is as important as explaining what it does. DIAM demonstrates the architecture and proves the concepts work. Productionising it is a significantly larger engineering effort.
Comments
Post a Comment