Security #25

New Issue

ahtlon · 2026-08-05T04:03:53+02:00

ahtlon commented

2026-08-05 04:03:53 +02:00

The nuki-hub and raspi will for the forseable future be on the (public) malobeo wifi network.
That means we should secure against ppl

logging in to the gatekeeper (username+pw[done])
logging in to the nuki-hub (has username+pw option [not setup yet])
spoofing the mqtt messages (mosquitto has username+pw option [not setup yet])

I don't know what the attack surface is regarding MITM in a network with WPA2/3 but everything should probably also use tls.

Mosquitto [not setup]
gatekeeper [reverse-proxy?/not setup]
nuki-hub also supports certs [not setup]

The nuki-hub and raspi will for the forseable future be on the (public) malobeo wifi network. That means we should secure against ppl - logging in to the gatekeeper (username+pw[done]) - logging in to the nuki-hub (has username+pw option [not setup yet]) - spoofing the mqtt messages (mosquitto has username+pw option [not setup yet]) I don't know what the attack surface is regarding MITM in a network with WPA2/3 but everything should probably also use tls. - Mosquitto [not setup] - gatekeeper [reverse-proxy?/not setup] - nuki-hub also supports certs [not setup]

kalipso commented

2026-08-06 14:48:23 +02:00

Protection against MITM attacks is linked to malobeo/infrastructure#40. Putting such devices onto a segregated network reduces the attack surface a lot. Since door access is kind of critical i suggest that we take care of this in the near future.

Regarding tls on the internal network we can use the same approach as with our .hq domains. This should at least work for gatekeeper.

As discussed yesterday i suggest splitting the scanner and gatekeeper functionality in the future - meaning we can host gatekeeper as microvm, and the scanner component runs on the rpi. When a card gets scanned, the scanner component could send access requests with card details to an gatekeeper api endpoint. Gatekeeper verifies the request and opens the door if the request is valid.
This way on the scanner (rpi) no sensitive information besides an api token is stored, meaning a compromised device wont gain full controll.

Protection against MITM attacks is linked to https://git.dynamicdiscord.de/malobeo/infrastructure/issues/40. Putting such devices onto a segregated network reduces the attack surface a lot. Since door access is kind of critical i suggest that we take care of this in the near future. Regarding tls on the internal network we can use the same approach as with our `.hq` domains. This should at least work for gatekeeper. As discussed yesterday i suggest splitting the scanner and gatekeeper functionality in the future - meaning we can host `gatekeeper` as microvm, and the `scanner` component runs on the rpi. When a card gets scanned, the scanner component could send access requests with card details to an `gatekeeper` api endpoint. Gatekeeper verifies the request and opens the door if the request is valid. This way on the scanner (rpi) no sensitive information besides an api token is stored, meaning a compromised device wont gain full controll.

ahtlon added the improvement label 2026-08-07 23:11:43 +02:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: malobeo/gatekeeper#25