keycardAccess issueshttps://git.mittelab.org/proj/keycard-access/-/issues2024-01-03T22:15:59Zhttps://git.mittelab.org/proj/keycard-access/-/issues/10What to do with logs if MQTT is down2024-01-03T22:15:59ZAljaž Srebrničpresidente@mittelab.orgWhat to do with logs if MQTT is downWe need to check what does the default library do if the connection is down. If not, we need to cache the logs.We need to check what does the default library do if the connection is down. If not, we need to cache the logs.https://git.mittelab.org/proj/keycard-access/-/issues/9Logs and rules backend plan2023-11-19T16:19:34ZAljaž Srebrničpresidente@mittelab.orgLogs and rules backend plan# Participants
## Broker
a MQTT broker using SSL. A good candidate is [rmqtt](https://github.com/rmqtt/rmqtt), since it has:
- webhooks to autid who connects to the broker
- HTTP auth support to dynamically enable gates
## Devi...# Participants
## Broker
a MQTT broker using SSL. A good candidate is [rmqtt](https://github.com/rmqtt/rmqtt), since it has:
- webhooks to autid who connects to the broker
- HTTP auth support to dynamically enable gates
## Device
the gate
## Web UI
the web backend to see logs and update rules
## Auth Backend
a backend (which may or may not be the same as Web UI) to handle gate MQTT authentication
# Connection
```mermaid
sequenceDiagram
participant D as Device
participant B as Broker
participant S as Web UI
participant A as Auth Backend
S->>B: Subscribe to /announce for new announcements
S->>B: Subscribe to /logs
D->>B: Publish to /announce/gate
S->>A: Create account for new gate
critical Reconnect to Broker with credentials
D->>B: Login
B->>A: Check credentials
A->>D: Auth success
end
activate D
D->>B: Publish logs to topic
D->>B: Subscribe to rules update
S->>B: Publish new rules
deactivate D
```
## Use DNS discovery to find broker
### TODO Should we save the mqtt broker address to flash?
IMO yes, we should.
## Connect without credentials, publish to topic `/announce/gate`
## Announce new gate payload
```json
{
"id": 1,
"key": "base64 encoded public key"
}
```
## Backend creates new account deriving password from key
We could mix the current timestamp in the password to have a “rolling” password, but it may be more trouble than it’s worth.
## Device does the same and authenticates to MQTT Broker
## Device publishes logs
```json
{
"id": 1,
"log": "Something happened"
"severity": "info"
}
{
"signature": "base64 signature of previous object"
}
```
# Open points
## TODO We need sNTP on the gates
## TODO SSL Certificate pinning of broker
## TODO should we structure logging more?
## TODO How should we do rules signing?
### Option A: rules get passed to the keymaker, which signs them and return the signature
this makes updating the rules cumbersome
### Option B: keymaker delegates rules signing to the backend
This implies we have some kind of CA-like structure, but this can get complex really fast
### Option C: compromise between the two
We specify another key during gate rollout (or even during the first registration) which will be used to check rules signature
### Option D: Just use MQTT
assume MQTT will not get breached and trust that only the backend can publish to the rules topic (of course the proper ACL needs to be set up)https://git.mittelab.org/proj/keycard-access/-/issues/8Programmer UI2023-01-16T22:28:33ZPietro SaccardiProgrammer UI1. Setup token (writes identity onto token, sets up root password)
2. Enroll token to gate (enables the token to authenticate at the given gate)
3. Configure gate (exchanges keys between gate and programmer)1. Setup token (writes identity onto token, sets up root password)
2. Enroll token to gate (enables the token to authenticate at the given gate)
3. Configure gate (exchanges keys between gate and programmer)Aljaž Srebrničpresidente@mittelab.orgAljaž Srebrničpresidente@mittelab.orghttps://git.mittelab.org/proj/keycard-access/-/issues/5Create basic requirement list2023-01-24T01:15:45ZAljaž Srebrničpresidente@mittelab.orgCreate basic requirement list## Core functionality
- [ ] We should be able to deny access to a member without having access to their card
- [X] We should be able to handle an arbitrary number of doors
- [ ] We should be able to handle access to equipment (laser, 3D ...## Core functionality
- [ ] We should be able to deny access to a member without having access to their card
- [X] We should be able to handle an arbitrary number of doors
- [ ] We should be able to handle access to equipment (laser, 3D printer)
- [X] Programming a card for a new member should be easy
## Security
- A database dump will not allow to craft new keys
- A database dump will not allow user impersonation
- [X] Physical access to the controller will not allow crafting new keys (buy may allow opening the door)
- [ ] Physical access to the external part (PN532 reader and button) will not allow opening the door
## Robustness
- The system should work if internet is down
- The system should work if internal network is down
- The system should work if power is down (fallback to physical key or battery backup)MVPAljaž Srebrničpresidente@mittelab.orgPietro SaccardiAljaž Srebrničpresidente@mittelab.orghttps://git.mittelab.org/proj/keycard-access/-/issues/2User interaction sequence2022-07-01T20:20:37ZAljaž Srebrničpresidente@mittelab.orgUser interaction sequenceThe system shall have (at least) three states:
* Closed: Only select members can open the door
* Open for members: All members can open the door
* Open for public: Door is automatically opened with front button
```mermaid
flowchart LR
...The system shall have (at least) three states:
* Closed: Only select members can open the door
* Open for members: All members can open the door
* Open for public: Door is automatically opened with front button
```mermaid
flowchart LR
press(Press button) --> open_for_public{Open for public?}
open_for_public --"no"--> reading(Read card)
open_for_public --"yes"--> open(Open door)
reading --"authenticate"--> member{is member?}
member --"no"--> do_nothing(Do nothing)
member --"yes"--> open_for_members{Open for members?}
open_for_members --"no"--> authorized{Authorized?}
open_for_members --"yes"-->open
authorized --"no"-->do_nothing
authorized --"yes"-->open
```MVP