←back to thread

Show HN: Open-source private home security camera system (end-to-end encryption)

(github.com)
551 points arrdalan | 2 comments | 30 Nov 24 22:13 UTC | HN request time: 0s | source

I needed a security camera inside my house, one that would send motion notifications to my smartphone and would allow me to livestream remotely. However, I could not find one that I could trust due to privacy concerns. Many of them upload the plaintext of videos to their servers and none is fully open-source as far as I know. Therefore, I decided to use my spare time to build one from scratch. Called Privastead (as in Private Homestead), it uses OpenMLS for end-to-end encryption (between the camera local hub and the smartphone) and is mostly implemented in Rust (except for part of the Android app that is implemented in Kotlin). The system is functional now and I've been using it in my own house for the past couple of weeks.

Based on some of the discussions I've seen online, it seems like there are other users who are also concerned with the privacy implications of home security cameras. Therefore, I decided to open source my solution for everyone to use. If you need a privacy-preserving home security camera, please give it a try and provide feedback. Note that trying out the system requires you to have a supported IP camera, a local machine connected to the IP camera, a server, and an Android smartphone. I have put together detailed instructions on setting up the system, which I hope makes it easier for others to get the system up and running.

In addition, consider contributing to the project. The prototype currently has a lot of limitations: mainly that it has only been tested with one IP camera, only allows the use of one camera, and only supports Android. I'll continue to improve the prototype as time permits, but progress will be much faster if there are other contributors as well.

Show context
SahAssar ◴[01 Dec 24 12:28 UTC] No.42288089[source]▶
I'd assume that end-to-end encryption would mean the traffic is encrypted between the camera and the app, which it isn't. That would require an app in the camera to support the system (which could be done on many cameras).
replies(2): >>42288568 #>>42291093 #
arrdalan ◴[01 Dec 24 14:19 UTC] No.42288568[source]▶
The traffic is encrypted between the hub and the app. The camera is connected to the hub.
replies(1): >>42288613 #
SahAssar ◴[01 Dec 24 14:30 UTC] No.42288613[source]▶
Right, but the "ends" in end-to-end encryption are typically the device producing the content and the device consuming the content. In this case that is the camera and the app.
replies(1): >>42290608 #
arrdalan ◴[01 Dec 24 20:46 UTC] No.42290608[source]▶
Correct, that would be even better, but I didn't have control over the camera firmware. Someone mentioned OpenMiko, which I plan to investigate and see if it can allow me to effectively run the hub inside the camera itself and achieve what you are referring to.
replies(1): >>42290719 #
SahAssar ◴[01 Dec 24 21:04 UTC] No.42290719[source]▶
I'd probably change that in your readme then, this is usually called something like encrypted in-flight or transport encryption.

End-to-end encryption is a pretty specific term and clearly not what is done here. Even if you use protocols designed for end-to-end encryption that does not matter if the protocols talk with an intermediary (the hub) that decrypts the traffic.

For example, if signal still used the signal protocol but decrypted the messages on their server that would not be acceptable to be called end-to-end encryption.

replies(2): >>42292567 #>>42292771 #
arrdalan ◴[02 Dec 24 03:18 UTC] No.42292771[source]▶
The end-to-end encryption part is clear IMO: it's between the hub and the app, both of which are trusted. This is different from an untrusted server decrypting the messages.
replies(1): >>42293786 #
1. SahAssar ◴[02 Dec 24 06:57 UTC] No.42293786[source]▶
The point of end-to-end encryption to me is that I don't need to have a trusted intermediary (in this case the hub).

Anyway, either way it's probably good to include something about how the traffic between the camera and the hub is completely plaintext and unencrypted and includes the password to the camera (unless I'm missing something), so even in your model it's not just the hub that is an additional point that needs to be trusted, it's also the whole network that they are on. That's probably at least a router and might include many other devices, sometimes quite untrusted.

Since some cameras support adding TLS/HTTPS it would be good to add support for that by not hardcoding http for the onvif endpoints. I think FFMPEG supports rtsp over tls out of the box.

replies(1): >>42295809 #
2. arrdalan ◴[02 Dec 24 13:08 UTC] No.42295809[source]▶
I have mentioned the unencrypted traffic between the camera and hub here: https://github.com/privastead/privastead/blob/main/HOW_TO.md (Step 4, second paragraph)