Adaptive MFA with Cryptographic Transaction Verification
Role
Product Designer Developer
Timeline
36 hours October 2024
Stack
React Native · Expo Stripe API · C2PA
Recognition
Finance Track Winner
🏆 HackHarvard 2024
Overview
People lie. Cryptography doesn't.
C2Pay is an adaptive MFA SDK my team built in 36 hours at HackHarvard. It scores payments in real time using device signals, motion patterns, and biometrics. It only asks for extra verification when something actually looks off. Clean sessions see nothing; suspicious ones hit a biometric check and get a cryptographically signed receipt.
36h
Built end-to-end at HackHarvard
548
Bits of combined security
2332
Operations to break the system
The Problem
Static auth treats every payment the same. That's the problem.
Most MFA is all-or-nothing: add friction everywhere, or nowhere. Low-risk purchases get the same hoops as fraud attempts. It's not a security strategy, it's just annoyance at scale.
"If a transaction looks exactly like you from your usual device at your usual time, why are we making you prove it twice?"
A C2PA-signed transaction manifest, machine-verifiable proof of device, user, and timestamp
What I Built
An SDK that scores the risk, then decides how much auth is needed
It sits between the checkout UI and the payment processor. Signals go in, a risk score comes out, and the SDK decides whether to pass the transaction through or escalate. All through a single C2Pay.verify() call.
Adaptive Risk Scoring
Location, motion, and tap cadence feed a real-time score. Auth only kicks in past a configurable threshold.
Biometric + Behavioral MFA
Face ID adds 20 bits; behavioral patterns add 64 more. Harder to spoof than a static password.
TEE-Backed Keys
Keys live in the Trusted Execution Environment, isolated from the OS. Signing never leaves the secure enclave.
C2PA Receipts
Every payment generates a signed manifest: device, user, timestamp. Anyone with the public key can verify it.
Demo: low-risk purchase passes through; high-risk purchase triggers biometric verification and generates a C2PA receipt
Real-time risk scoring dashboard
Verification success state with C2PA receipt
Technical Approach
The decisions that actually mattered
Why C2PA? It was designed for media provenance, not payments. But a C2PA manifest is just a JSON-LD document signed with an asymmetric key. We repurposed it for transactions: same format, same verifiability, completely different context.
Why Ed25519? Fast signing on mobile. Under 1ms, tiny keys, 128-bit equivalent security. RSA-2048 would have been slower and overkill for the demo.
The pivot: We started with AI image detection. Four hours in we realised the core primitive, cryptographic attestation, was more directly useful for payments. Narrower scope, cleaner demo, won the track.
System architecture: signal collection → risk score → conditional escalation → C2PA manifest generation
Security bit breakdown
We checked that stacking factors actually added independent entropy, not just redundancy:
20
bits / Face ID (1-in-1M FAR)
64
bits / Behavioral patterns
80
bits / TEE device attestation
128
bits / Ed25519 signature
256
bits / SHA-256 hash
Combined: 548 bits total, effective attack complexity of 2332 operations (more than atoms in the observable universe)
What I Learned
What I took away from 36 hours of cryptography
Cut scope, not corners. The pivot made the submission better, not worse. We could explain exactly what it did and why the math held. I've seen a lot of hackathon projects die from trying to demo everything.
Standards are free engineering. C2PA saved us hours. We didn't design a manifest format. We just used the one Adobe, Microsoft, and Google already agreed on. In a hackathon, building on established protocols is the move.
Auth is a spectrum. Not every action needs the same friction. Since C2Pay, I think about security UX in tiers: what's the action, what's the risk, what's proportionate?
