Actions
Forum Thread Details
  • Replies 7 replies
  • Subscribers 45 subscribers
  • Views 184 views
  • Users 0 members are here
Related

Identity Protocol - Part 2 - Django Server

arvindsa

Recap:

The idea is simple enough: stop making people swipe a card and type a PIN at every single door. Instead, the ID card (a MAX32630FTHR + ATECC508A in your pocket) unlocks once via PIN, then silently does challenge-response crypto over Bluetooth every time you walk up to a door. If the card gets yanked off you, the IMU detects the tug and it locks itself. No PIN, no entry. For more details check the Part 1 of the series

The Sponsored kit is on the way, and Scheduled to be delivered this Saturday.  I am gonna be travelling from Satuday morning to Wednesday Night, This was planned earlier and so as per that plan, I am making the Django server first

Server Architecture Overview

There are two distinct types of clients, One will be the Door device and the other is Browser being accessed by security for evaluating logs and analytics, each with their own authentication path hitting separate sets of endpoints. The request routing:

Request

And the five database models with their relationships:

image

The two auth paths are the key structural decision here — more on that below.

The server is plainly a Proof of Concept. Therefore, I am not implementing any production-grade access control management system — it just needs to do two things well enough to demo the protocol: hand out public keys to doors, and receive access logs. Anything beyond that is a bonus.

That said, I ended up building a fair bit more than the bare minimum because the admin dashboard and analytics make demos much more compelling.

Models

There are five models. Four of them map directly to real-world entities in the system:

IDDevice - represents one ID card. Stores the owner's name and email, the ATECC508A's public key (DER-encoded, hex), a status ('active', 'inactive', 'lost'), and a 'last_seen' timestamp updated on each successful access. The public key is what gets handed to doors so they can verify signatures.

DoorDevice - a door controller. Has a name, location string, its own public key, a status, and a last_heartbeat timestamp. Each door gets an API key (see below) to authenticate with the server.

AccessEvent -  the audit log. Every authentication attempt — success or failure — gets written here by the door, with a timestamp, which ID card and door were involved, and the result. The result field covers the interesting failure modes specifically: bad signature, blacklisted card, PIN timeout, tug detected. This is where you'd look to investigate anything suspicious.

Blacklist - revoked ID cards. When a card is reported lost or stolen, it goes here. The door can either poll `GET /api/blacklist-check/<device_id>/` per-card, or fetch the whole list at once with `GET /api/blacklist-sync/` and cache it locally. Local caching is the better option — it means the door can still reject blacklisted cards even if the server goes down.

DeviceAPIKey - lightweight auth for door-to-server communication. No JWT, no OAuth dance — a door just sends `Authorization: Api-Key <key>` in the header. The key is generated with `secrets.token_hex()` and stored in the database. The admin creates these keys and provisions them onto door hardware during setup. Each key tracks `last_used`, which is a nice sanity check during debugging.

Authentication Design Decision

There are two completely separate authentication mechanisms here, for two completely different clients.

Door devices use an API Key system -  a static token in the `Authorization: Api-Key <token>` header. Ideally, I should implement more secure system but as i said before, this is a proof of concept for and so a token stored in flash, issued once during setup, is simple and easy to implement.

The admin browser uses Django's standard SessionAuthentication. it just works for a browser-based admin UI.

API Endpoints

Device-facing

  • GET /api/keys/<device_id>/ - Fetch an ID card's public key
  • POST /api/events/ - Log an access attempt
  • GET /api/blacklist-check/<device_id>/ - Check if one card is blacklisted
  • GET /api/blacklist-sync/ - Fetch the full blacklist for local caching

Dashboard/analytics

  • GET /api/dashboard/stats/ - Today's and this week's access counts + success rates
  • GET /api/dashboard/per-door/ - Per-door stats + hourly breakdown
  • GET /api/dashboard/per-device/ - Per-ID-card access frequency
  • GET /api/dashboard/security/ - Recent failures, tug detections, suspicious devices
  • GET /api/dashboard/trend/ - Daily totals for charting (last N days)

Plus the standard DRF viewset CRUD routes for 'id-devices', 'door-devices', 'access-events', and 'blacklist'.

The Admin Dashboard

There's a custom admin dashboard at `/dashboard/` — a separate Django app with Bootstrap 5 templates and its own session-authenticated views. It's separate from Django's built-in admin (still present at `/admin/` for low-level data access). I am building my UI using the ever awesome AdminLTE theme.

  • Overview - Live stats: today's and this week's totals + success rate, 7-day sparkline, recent events feed
  • ID Devices - Full CRUD: register, edit, delete, search/filter by status
  • Door Devices - Full CRUD: register, edit, delete, filter by status
  • Event Log - Browse all access events, filter by result, door, date range
  • Blacklist - Blacklist a device, remove entries
  • API Keys - Create and revoke door device API keys
  • Analytics - Charts: daily trend, result breakdown, per-door stats, suspicious device detection

Screenshots

Dashboard

image

Door Device CRUD

image

Access Log

image

Device Keys

image

Analytics

image

There are some bugs i need to crush. Will post the Source code post that

  • pretty cool setup - is the whole admin interface above something that comes with Django? or is it built from scratch? I presume some kind of library?

    I do like the idea of your encryption running via a chip ATECC508A, I env ordered some to have a bit of a play.

    I know that this is a PoC (proof of concept) but it always interests me to take a look at vulnerabilities in a security system. What I can see so far:

    1. enumerable ID's for GET /api/keys/<device_id>/ presumably ID-001, ID-002 as this is an unauthenticated endpoint does that mean I can find out who works there?
    2. is there a chance of a man-in-the-middle attack with a server? is there any auth proving that the server is the right one to respond with? I presume you could:
      1. TLS certificat pinning?
      2. HMAC - respond with an X-signature that is HMAC-SHA256 over the body using the door's API key as the HMAC secret
      3. mTLS - Mutual TLS - set the CA certificates ahead of time

    anyway, interested to see how it all works out in the end - good luck

  • in reply to saramic

    You've asked some serious questions and i love it. Django calls itself a "battery included " framework and comes with almost everything needed to prototype  a web app and thus it includes  its own admin interface which is next best thing to editing data on the database directly.  But it cannot be styled well, so I developed a custom one from scratch. Now, To answer your questions,

    1. The enumeration shown is only for easy understanding,  it can be a uuid or any unique random string. 

    2. In ideal case, these system should be firewalled to access only internal networks and would require tls pinning or mTLS to avoid mitm attack. mTLS is something the ATECC508A  can do well, although its limited to some 16 single write slots for the encryption key.  for an proper mtls rotation system as required for an ideal security system with attec508a il have to the mtls keys encrypted by one a dedicated key in the ATECC508A and have the ciphertext saved in a general flash chip. I'm not sure if I can achieve that within the timeline of this challenge though

    Would've been lovely to implement though.  

  • in reply to saramic

       I just saw the selected challenger.  I'm sorry that your ideas were not selected,  but id like to hear out your ideas if it's okay for you to share it.

  • in reply to arvindsa

    I mean I can still challenge - although I only now ordered the MAX32630FTHR# and reading some of the forums on the dev env setup, I am not sure I will achieve much ¯\_(ツ)_/¯ - all my submissions can be found under https://github.com/saramic/sentinel-box I had 4 but only now realised I probably didn't give enough details about me and what exactly I was going to build. The idea I wanted to build was some kind of RF detector to fingerprint when something like a drone is flying overhead (not sure how possible it is but there are things like this https://www.blue-bird.tech/en/products/drone-detector-chuika-2-0-1-3-ghz-and-5-8-ghz/ so who knows. In the end I am planning to build a Sentinel-box - a family lock box for digital distractions that can be locked and requires various factors of complexity to unlock - I will see how far I go here. The idea is to do something relatively simple - the MAX32630FTHR# processes a wake word and runs a stepper motor to open a box - and extend it with other things like NFC, finger prints, I will see if I have enough time to take it much further than the basics - I am also hoping to maybe be selected for the UNO Q design challenge https://community.element14.com/challenges-projects/design-challenges/on-the-line/dc/dc/83/on_the_line_design_c - I just bought an UNO Q and spent the best part of the weekend playing with it - the idea of a chip that can run a full dockerised build right there next to an arduino is kind of cool, I got a web cam connected and running a model to detect a person seemed to work pretty well once I turned the window manager off on the 2GB model

  • in reply to saramic

    Interesting idea. I really dont think the "about me" part in a proposal matters. The e14 team has been selecting the challengers purely on the basis of the parameters they mentioned in the Rules. The contents invite all makers. 

    Ive applied to the On the line challenge as well. Its Summer vacation time and I do have some extra time on my hands. And Yes, Arduino Q isn't the first one to do it. Beagle bone had a linux chip and a PRU though It was complicated.  But Q hopefully makes the system easily accessible for all. 

  • in reply to arvindsa

    In addition to sharing plenty of detail on a proposed project in a design challenge application, I would certainly encourage folks to include some detail on themselves if it seems relevant and you think would strengthen your application.

    For example:

    • Maybe you have worked on something previously which connects to the design challenge's kit or theme and will help you build your project.
    • If you were submitting a super ambitious proposal then maybe you could demonstrate prior experience with similar work to show you can bring the project to life in the timeframe of the competition.
    • Whether you are on summer vacation and have plenty of free time (or conversely you have a limited window when you can work on something) is useful to know.
  • in reply to JoRatcliffe

    Thank you so much for the clarification. Slight smile