Threat Model

This document analyzes the security threats to the OpenLatch door lock system and the mitigations in place.

Assets

Asset	Value	Location
Physical access to the space	High	Door
Member personal data	Medium	Backend database
Admin credentials	High	Backend database
Ed25519 signing key	Critical	Backend env var
WiFi credentials	Medium	ESP32 NVS
Device auth token	Medium	ESP32 NVS
Audit log	Medium	Backend database

Threat Actors

Actor	Capability	Motivation
Opportunistic intruder	Low tech, no insider knowledge	Theft, vandalism
Lost/stolen card holder	Has a valid NFC card	Unintentional — card may be used by finder
Disgruntled ex-member	Knows the system, may have old card	Unauthorized access
Technically skilled attacker	Can intercept signals, clone cards	Targeted unauthorized access
Insider threat (admin)	Full backend access	Data manipulation
Network attacker	Can intercept WiFi traffic	Man-in-the-middle

Threats and Mitigations

T1: Stolen or Lost NFC Card

Risk: Someone finds/steals a card and uses it to enter.

Mitigations: - Member reports lost card → admin revokes it immediately via admin UI - Next allow-list sync (within 5 minutes) removes the card from ESP32 - Audit log shows when the card was last used - Short sync interval (5 min) limits the window of exposure

Residual risk: Up to 5 minutes of unauthorized access before sync. Acceptable for a hackerspace.

T2: NFC Card Cloning

Risk: Attacker clones a member's NFC card.

Mitigations: - MIFARE DESFire EV2/EV3 cards use challenge-response authentication — cannot be cloned by reading the UID alone - The CONLAN M1200 terminal handles the DESFire authentication internally - Unlike MIFARE Classic, DESFire has no known practical attacks on the crypto

Residual risk: Supply-chain compromise of NXP's DESFire crypto is theoretically possible but extremely unlikely.

T3: Wiegand Signal Interception

Risk: Attacker taps into the Wiegand wires between terminal and ESP32 to capture UIDs.

Mitigations: - Wiegand wires run inside the wall from the outdoor terminal to the indoor ESP32 - Physical access to the wires requires opening the wall or terminal housing - The terminal housing should be tamper-resistant with tamper detection (CONLAN M1200 supports this)

Residual risk: An attacker with physical access to the wall cavity could tap the wires. This requires significant effort and is detectable. Wiegand does not encrypt data — this is a known protocol limitation.

Future improvement: Consider OSDP (Open Supervised Device Protocol) which encrypts the reader-to-controller communication. Requires an OSDP-compatible reader.

T4: Man-in-the-Middle on WiFi

Risk: Attacker on the same WiFi network intercepts or modifies the allow-list payload.

Mitigations: - All communication uses HTTPS (TLS encryption in transit) - The allow-list payload is Ed25519-signed — even if TLS is somehow broken, the ESP32 rejects unsigned or wrongly-signed payloads - The ESP32 uses certificate pinning (or CA verification) for the backend

Residual risk: Negligible. The attacker would need to compromise both TLS and the Ed25519 signing key.

T5: Replay of Old Allow-List

Risk: Attacker captures a valid signed allow-list and replays it later to re-enable a revoked card.

Mitigations: - Monotonic version number: ESP32 rejects any allow-list with version <= current_version - Validity window: valid_until is set to generated_at + 24 hours, limiting the time window - Signature covers the version and valid_until, preventing modification

Residual risk: None, unless the attacker can downgrade the ESP32 firmware to reset its version counter. See T8.

T6: Backend Server Compromise

Risk: Attacker gains access to the backend server and signs arbitrary allow-lists.

Mitigations: - Ed25519 signing key is stored as an environment variable, not in the database or repository - Server hardened with SSH key-only access, no password auth - Regular security scanning in CI (pip-audit, dependency checks) - Audit log records all changes to members, keys, and rules - Two-person rule: critical changes (e.g., adding admin accounts) should be reviewed

Residual risk: A compromised server with the signing key can generate valid allow-lists. Mitigation: store the signing key in an HSM or separate machine for high-security deployments.

Future improvement: Hardware Security Module (HSM) or Vault for key storage.

T7: ESP32 Physical Access

Risk: Attacker gains physical access to the ESP32 and extracts WiFi credentials, device token, or allow-list.

Mitigations: - ESP32 is mounted inside the space (not accessible from outside) - NVS encryption protects WiFi credentials and device token - Flash encryption (eFuse-based) protects firmware and LittleFS data in production - The Ed25519 public key is not secret (it only verifies, cannot sign) - The allow-list contains UIDs which are not secrets (the NFC card itself is the secret via DESFire)

Residual risk: An attacker inside the space with extended physical access to the ESP32 could potentially extract data despite encryption. This requires the attacker to already be inside.

T8: Firmware Tampering

Risk: Attacker flashes malicious firmware to the ESP32.

Mitigations: - ESP32 flash encryption in release mode makes firmware read-only (eFuse-based, one-time) - Secure Boot verifies firmware signature before execution - Physical access required (USB connection or JTAG)

Residual risk: Development-mode flash encryption allows re-flashing. Production deployment should use release-mode flash encryption.

T9: Denial of Service (Backend Down)

Risk: Backend is unreachable — ESP32 cannot sync allow-lists.

Mitigations: - Offline-first design: ESP32 uses the last valid allow-list from LittleFS - UNRESTRICTED and EMERGENCY entries continue to work even with stale list - valid_until window (24 hours) gives ample time to restore the backend - NUKI Smart Lock Ultra has battery backup, ESP32 can be on a UPS

Residual risk: If the backend is down for more than 24 hours, SCHEDULED entries are denied (cannot reliably evaluate time rules with stale data). UNRESTRICTED members can still enter.

T10: Power Outage

Risk: Power failure at the space.

Mitigations: - NUKI Smart Lock Ultra runs on batteries (independent of ESP32 power) - NUKI retains its locked/unlocked state through power loss - ESP32 reboots and loads allow-list from LittleFS flash (non-volatile) - Consider UPS for ESP32 for uninterrupted operation

Residual risk: During ESP32 reboot (~2-5 seconds), NFC access is unavailable. NUKI can still be operated manually or via the NUKI smartphone app.

T11: Insider Threat (Admin Abuse)

Risk: A malicious admin adds unauthorized keys or modifies rules.

Mitigations: - Audit log records all admin actions with actor ID and timestamp - Audit log is append-only (no delete endpoint) - Regular audit log review by the hackerspace community - Principle of least privilege: separate admin/keyholder/member roles

Residual risk: An admin with database access could modify the audit log directly. Mitigation: use database-level audit logging or write-ahead log shipping.

Risk Summary

Threat	Likelihood	Impact	Residual Risk
T1: Stolen card	Medium	Medium	Low (5 min window)
T2: Card cloning	Very Low	High	Very Low (DESFire)
T3: Wiegand interception	Low	High	Low (physical access needed)
T4: WiFi MITM	Low	High	Very Low (TLS + Ed25519)
T5: Replay attack	Low	Medium	Very Low (monotonic version)
T6: Server compromise	Low	Critical	Medium (signing key exposure)
T7: ESP32 physical	Low	Medium	Low (encryption + inside mounting)
T8: Firmware tampering	Very Low	Critical	Low (secure boot + flash encryption)
T9: Backend DoS	Medium	Low	Low (offline-first)
T10: Power outage	Medium	Low	Very Low (battery + flash)
T11: Insider threat	Low	High	Medium (audit log)

Recommendations for Production Deployment

1. Enable ESP32 flash encryption in release mode (one-time eFuse burn)
2. Enable ESP32 Secure Boot to prevent firmware tampering
3. Use a dedicated WiFi network for the ESP32 (isolated from member WiFi)
4. Store the Ed25519 signing key in a hardware security module or at minimum a secrets manager
5. Set up automated alerts for: emergency key usage, admin actions, failed sync attempts
6. Regular key audits: periodically review active keys and revoke unused ones
7. Physical tamper detection: configure the CONLAN M1200's tamper alarm output