Security

[bcutter]

This is not an issue. It's a question (probably discussion), as next to the generic note in the license file I couldn't find anything about it and there's no discussion section in this repo, so:

What about security of this project?

When I was telling a friend of this great, widely used Nuki Hub, he was asking me: Dude, it's all about the access to your home. Do you really want to trust a FOSS project instead of relying on the manufacturer by e. g. using the official Nuki Bridge?

This question is in my head, even after days.

Nuki solved few security issues in their firmware including the Bridge this year (https://www.heise.de/news/Sicherheitsluecken-als-Tueroeffner-in-Nuki-Smart-Lock-entdeckt-und-geschlossen-7194709.html, one might use Google Translate), so no, "original software/hardware != secure automatically". And looking at the interval new releases are shipped here, speed is another thing this project outperforms Nuki.

• But what are the basic libraries used which are out of control of this project?
• Any other core components relevant in terms of security?
• Using no encryption for the MQTT topics might be an actual risk, assuming your WiFi is compromised etc. (in that case, there might be other much more serious issues).

Enough brainstorming. Two core questions:

1. So at the end, what actual risk remains when using the Nuki Hub compared to the Nuki Bridge?
2. What potential security risks are added to the overall Nuki usage by using this Nuki Hub?

[technyon]

Let me start by saying that if someone wants to open your door (e.g. burglary), they will won't go such sophisticated measures as hacking your smartlock. Using brute force will be much easier in most cases. That being said, we shouldn't neglect security.

You'll find most libraries being used in the "lib" subdirectory:

• NukiBleEsp32 for the bluetooth communication with the lock, which in turn uses NimBLE, crc16 and BleScanner. The latter is developed by the devs of NukiBleEsp32 and me, but nothing too security relevant, it receives the BLE beacons and forwards them.
• WebServer for the configuration portal
• WiFiManager for the Wifi setup
• PubSubClient for MQTT communication
• MqttLogger to log to mqtt
• Arduino core for ESP32 (needs to be installed on the build system; included via cmake)

Although most people will run MQTT without encryption, it's possible to use certificates encrypt all traffic ... only over Wifi unfortunately because the W5500 driver lacks support for this.

Is it safer than the official bridge? Hard to tell, since we don't have the source code for the official bridge. I think not using a cloud solution is a big plus in regards to security (and privacy which matters for many people as well).

I'll do my best to make this as safe as possible, but bugs did happen. For example there was a bug that could trigger an unlatch if Wifi or power went down, and the action is still present in the MQTT topic. This is fixed now, thanks to an issue that was reported.

On the other hand, I guess NUKI ultimately has more ressources for development ... that includes things like QA and project management. NUKI Hub is mostly me, the devs of NukiBleEsp32 and a few contributors to this project (MQTT encryption for example).

[bcutter]

Thank you very much for answering in detail. Also for pointing out one general (non-technical) "security issue" which I had not on my list yet: you as the ultimate maintainer of this great project. Don't want to think about what happens if (security) things need to get fixed and you're not available for some time. Fair enough to point at this, thanks for your transparency.

Bugs always happen (I noted the ones affecting the locks including the official bridge from Nuki itself) and will happen. Nuki probably buys some time due to a vulnerability disclosure process, according to the heise article researches had a 3 months communication embargo. Here on GitHub it is important that things get fixed once they are publicly listed as security issue, so speed indeed is much more important for FOSS compared to the proprietary/non-public development.

Technically: plenty of components, which all are maintained by their own (other maintainers). In the end all that still needs to get packaged to a new Nuki Hub release.

I'll draw my conclusion (probably "next year" 😉). Currently I have a Lolin ESP32 ("ESP32-WROOM-32") lying here next to an official Nuki bridge, together with a 3.0 and a 3.0 Pro (which should receive MQTT support at some time, currently there's a closed beta).
The Nuki bridge - according to some rumors - can also be downsized to use the local API only (disable web API or - hammer method - restrict internet access for the bridge), because you're absolutely right: anything but local is a failure by design in terms of security (rather privacy).

(Maybe we can leave this issue open for some time to see if others have questions/input too?)

[chatziko]

First of all, many thanks to everyone involved for this truly awesome project! I'm amazed by how well it works compared to everything else I tried.

Security-wise, there are pros and cons for using an open source project, but IMHO the pros greatly outweigh the cons:

• I can see the source of Nuki hub, audit it, and understand exactly what it does.
• Nuki hub will never make a cloud connection (eliminating a huge percentage of attack vectors)
• Nuki hub will never try to auto update to a new version with unknown functionality
• There is no financial incentive to add advanced features (eg interoperability with other cloud products) that could introduce more attack vectors.
• Nuki hub does not risk to start losing money and end up being sold to some untrusted company.
• Even if its maintainer abandons the project (please don't :D), anyone can step up and take over (it's a small codebase, not anything crazy).

After the Eufy fiasco, the above points have become way more important than development ressources.

[iranl]

In accordance with https://docs.github.com/en/get-started/using-github/communicating-on-github#scenarios-for-github-discussions this (very interesting, perpetually relevant) open-ended conversation is more suitable for the discussions section imho.

@technyon: Now that GitHub discussions is enabled on the repository I propose we convert this issue to a discussion.