Close
0%
0%

Kindly Identify Yourself

Server-side access control with ESP32 readers, fingerprint, NFC, and an Android phone key. The reader only relays, the server decides.

strangerandstrange.rand
Following
Liked Like project

Just one more thing

To make the experience fit your profile, pick a username and tell us what interests you.

Pick an awesome username
hackaday.io/
Your profile's URL: hackaday.io/username. Max 25 alphanumeric characters.
Pick a few interests
Projects that share your interests
People that share your interests

We found and based on your interests.

Choose more interests.

OK, I'm done! Skip
Similar projects worth following
52 views
0 comments
1 followers
View Gallery
Most DIY access control projects let the device decide: a fingerprint module or a reader does the matching and, on “match is OK”, opens the lock. Whoever gets hold of that device, or can make it say “match is OK”, gets the door.

Here it’s the other way around. The reader (ESP32-S3 with an NFC front end) only relays what is presented to it. It has no keys, no “access granted” logic, and it cannot open the lock. A server does all the verifying and sends the lock a short-lived grant, so a hacked reader gives nothing.

For now, the credential is an Android phone. It signs a one-time challenge from the server with a private key that never leaves the phone’s hardware, and the server stores only the public key. There is a web admin UI and an audit log of every change. Home Assistant (or any other actuator) operates the lock.

Next: NFC cards, a bare fingerprint image sensor (matched on the server, images never stored), and PIN codes, with a minimum assurance level per lock.

Why

Most DIY access control projects I've seen let the device decide. A fingerprint module does the matching itself and talks to the ESP over a plain, unauthenticated UART, or a reader checks a card and sends the command that opens the lock. It's relatively easy to get to that wiring and make the device say "match is OK". A few modules do encrypt that link, but the key sits in the ESP's flash, and the same ESP still opens the door, so owning the ESP still means owning the door.

This project turns that around: the reader in front of the door is deliberately dumb.

The idea

  • The reader is an ESP32-S3 with an NFC front end, later also a bare fingerprint sensor and a keypad for a PIN. It relays what is presented to it and shows the result on an LED ring. It holds no keys and no templates, has no "access granted" logic, and cannot open the lock.
  • The server verifies the credential, whatever its kind (phone, card, fingerprint, PIN), and makes the decision. Then it sends the lock a short-lived grant.
  • Home Assistant, or any other actuator that accepts the grant, operates the lock. It does not decide who may enter.
Read more »

View all details

  • Reality check. Changing the concept.

    strange.rand • 7 hours ago • 0 comments

    Reality check

    Posted the idea of this project on Reddit and received valuable (negative) feedback.

    My motivation for moving matching to the server was:

    • More control: threshold, number of images per finger, auto-update of fingerprints (as smartphones do).
    • The decision is made not in the exposed region (reader).
    • Easier to manage (clean hierarchy: person -> finger -> templates) and better control over enrollment.

    The biggest downsides are:

    • The blast radius. With matching on a chip, a hacked server means someone can open your door. With matching on the server, it may lead to stolen fingerprint images or templates.
    • Fingerprints are non-revocable. A stolen fingerprint is forever.

    Here I need to note that probably all hobby-grade fingerprint sensors are vulnerable and may leak your fingerprints, as communication over unencrypted UART means anyone can send any command, including a template export or get a raw image. Despite the reconstruction of the original fingerprint image from the template being impossible (AFAIK), it is possible to construct a synthetic image that will pass the lock using that template.

    Changing the concept

    As of now, the idea is to support multiple authentication methods:

    • NFC using a smartphone (Android only)
    • NFC using a card (DESFire, NTAG 424)
    • Fingerprint
    • PIN

    The current phase is NFC using a smartphone, and it already works on the bench. The private key lives in the phone’s secure hardware and never leaves it. The server stores only the public key. Enrollment is done once (hardware attestation + manual approval). On every tap, the server sends a signed one-time challenge, the phone verifies it and signs it back. A recorded exchange can’t be replayed, and a leaked database has nothing to steal.

    I'm renaming the project to Kindly Identify Yourself (KIY). Naming a project is almost as hard as naming variables, and in this field, almost every good word is already taken. So I went to the Culture series by Iain M. Banks to find something interesting.

    What about a fingerprint reader?

    As of now, it is still planned, and I'm waiting for the sensors. I'll do what I can to reduce the risks (e.g., raw images won't be stored, and templates will be encrypted), and of course it'll be an optional method (probably with the possibility of disabling it during installation).

View project log

Enjoy this project?

Share

Discussions

Does this project spark your interest?

Become a member to follow this project and never miss any updates

Going up?

About Us Contact Hackaday.io Give Feedback Terms of Use Privacy Policy Hackaday API

© 2026 Hackaday

Yes, delete it Cancel

Report project as inappropriate

You are about to report the project "Kindly Identify Yourself", please tell us the reason.

Send message

Your application has been submitted.

Remove Member

Are you sure you want to remove yourself as a member for this project?

Project owner will be notified upon removal.