Inspiration
It started with a simple observation: every day, thousands of students and staff tap into Yeshiva University buildings with credentials that prove absolutely nothing about who is actually walking through the door. A borrowed card, a found card, a stolen card — they all open the same doors. The system validates what you have, not who you are.
We started asking questions. What happens when a lost ID card grants someone unauthorized access to a dormitory for hours before anyone notices? What does it mean for Clery Act compliance when the audit trail only says "card was tapped" but can't confirm who tapped it? What does personal safety in a residence hall look like when credential sharing is not just possible but normalized?
The more we dug, the more it became clear: this isn't a technology problem. It's an identity problem. And every student already carries the solution in their pocket.
What It Does
YU SmartPass transforms the smartphone every student and staff member already carries into a biometric-verified, cryptographically secured access credential — replacing the question of "do you have a valid card?" with "are you the authorized person?"
Here's how it works: a student approaches a secured door and opens their digital university ID stored in Apple Wallet or Google Wallet. YU SmartPass triggers an on-device biometric scan — Face ID, fingerprint, or secure PIN. Once verified, the system generates a one-time-use, cryptographically signed JWT token containing the user's identity, a timestamp, a unique nonce, and a device fingerprint. That token expires after 20 seconds or one successful scan, whichever comes first.
The door reader validates the token by checking the cryptographic signature, confirming the timestamp is within the 20-second window, verifying the nonce hasn't been used before, and confirming the credential is active. Access is granted or denied, and the event is logged with full identity attribution — not just "card tapped at 9:14 PM" but "Student/Staff", identity verified via Face ID, entered Main Entry at 9:14 PM."
The system also features tiered authentication: libraries and dining halls accept a standard NFC tap, dormitories require the full biometric-gated token flow, and high-security labs add a secondary PIN or supervisor approval layer. One framework, flexible friction.
How We Built It
We started with the security model before writing a single line of code. We mapped out the token lifecycle — generation, transmission, validation, expiration, and revocation — and identified every point where the current card-based system fails. That threat model became our architecture blueprint.
The prototype is built as a React application scaffolded with Vite. The core engine handles real JWT generation with proper header/payload/signature structure, enforces 20-second token expiry with a live countdown, and implements nonce-based replay protection that blocks reuse of any previously validated token. The audit trail captures every access event with full identity attribution: who, where, when, what authentication method, and whether access was granted or denied.
We designed the demo to simulate the end-to-end flow interactively — user enrollment, biometric authentication (visually simulated since real Face ID requires native device APIs), token generation with a visible countdown, door reader validation, and the access decision. We also built in a replay attack simulation so we could demonstrate the security model failing gracefully: same token, same tap, access denied — because the nonce was already consumed.
The biometric verification is offloaded entirely to hardware the user already owns. No biometric data ever leaves the device. YU SmartPass only receives a cryptographic assertion — never the biometric template itself. This was a deliberate architectural decision for both privacy (FERPA compliance) and cost (zero new biometric hardware required on campus).
Challenges We Ran Into
The biggest challenge was scope discipline. The full vision includes Apple Wallet PassKit integration, real NFC communication, backend credential management with instant revocation, and real-time occupancy dashboards. We had to constantly ask ourselves: does this feature prove the core concept, or is it engineering for engineering's sake?
Simulating the biometric authentication in a way that felt convincing without access to native device APIs required careful UX design. We needed the demo to clearly communicate that biometric verification is happening on-device without misleading anyone into thinking we built actual Face ID integration. The animated fingerprint scanner with a clear "simulated" label was our solution.
Token lifecycle management was another area where simplicity fought with correctness. A 20-second expiry window is tight — tight enough to kill credential sharing, but tight enough to cause problems if the demo lags. We tuned the flow so the token countdown is always visible, making the security constraint feel intentional rather than frustrating.
We also had to think carefully about edge cases that judges and professors would immediately ask about: dead phones, network outages, accessibility needs, device spoofing. Addressing these in the proposal (backup cards with usage limits, offline JWT validation with cached public keys, extended token windows for accessibility) took as much thought as the core system design.
Accomplishments That We're Proud Of
The replay attack demo is the moment that lands. You authenticate, generate a token, tap the reader, and access is granted. Then you hit "Simulate Replay Attack" — same token, same tap — and the system blocks it instantly. That single interaction communicates the entire value proposition better than any slide deck: we verify people, not credentials.
We're proud that the security model is real even though the prototype is simplified. The JWT structure, the nonce tracking, the expiry validation — these aren't mocked. They're functioning implementations of the actual cryptographic controls that a production system would use. The simulation layer is only in the I/O (biometrics and NFC), not in the security logic.
We're also proud of the tiered authentication design. It would have been easy to apply the same security level everywhere, but that's not how the real world works. A library doesn't need the same friction as a research lab. Matching security to sensitivity shows we thought about the user experience, not just the threat model.
What We Learned
Identity is the real perimeter. Firewalls, access cards, and PIN codes are all proxies for the question that actually matters: is this person authorized to be here? Once we reframed the problem as an identity verification gap rather than an access control gap, the solution became clear.
We learned that the best security systems are the ones people actually use. If the authentication flow takes longer than tapping a card, adoption dies. Offloading biometrics to the user's own device — hardware they already trust and unlock dozens of times a day — was the insight that made the entire system viable without adding friction.
We also gained a deeper appreciation for how much security theater exists in physical access systems. "Card was tapped" feels like a security event, but it's not. It's a proximity event. The difference matters legally (Clery Act), operationally (incident response), and personally (student safety in housing).
What's Next for YU SmartPass
Phase 1 — Wallet Integration: Native Apple Wallet and Google Wallet pass provisioning through the university portal, replacing the simulated wallet UI with real PassKit and Google Pay API integration.
Phase 2 — NFC Communication: Real NFC token transmission between the mobile app and door readers, replacing the simulated button-tap interaction with actual hardware communication.
Phase 3 — Backend Infrastructure: A centralized credential management server with instant revocation, public key distribution to readers, and a real-time admin dashboard showing building occupancy and access anomalies.
Phase 4 — Pilot Deployment: Partner with YU Campus Security and IT to pilot in a single dormitory, measure adoption, validate the threat model against real-world usage, and collect student feedback.
Phase 5 — Intelligent Monitoring: Layer behavioral analytics on top of the verified audit trail — detecting anomalies like access at unusual hours, rapid entry across distant buildings, or repeated backup-card usage that could indicate a compromised credential.
The long-term vision is a campus where every door knows not just that a credential was presented, but that the right person is standing in front of it.
Built With
- chatgpt
- javascript
- jwt
- node.js
- react
- vercel
- vite
