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.
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.
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.
Agreed, transport encryption is the term to use for this model which is a great model anyway.
You can use e2e if the data-at-rest (e.g., video) file(s) are also 100% encompassing the encrypted in both the camera and the remote server, as well as the mobile app and remote server.
From the client-side, this E2E means no raw data are exposed over network nor in remote storage and that keys are required to view the raw data at either endpoints.
In today's parlance, the undefined portion of E2E is whether the local storage is encrypted as well. Some will argue on this point. Future may (and should) tighten this E2E as well.
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.
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.
Good question. I'm not really familiar with insurance requirements. Privastead simply records videos from an IP camera and sends it to your phone. It does not modify the videos and hopefully that should be adequate for insurance companies.
A fully isolated setup can certainly provide good privacy. A key benefit of Privastead is that it can send the videos to your smartphone remotely using a strong (MLS-based) end-to-end encryption.
Privastead does not currently send thumbnails as part of the notifications. Performing proper end-to-end encryption on data in push notifications is a bit tricky and I haven't solved that yet. I do have some ideas on how to make that happen though. Once I do, I plan to add thumbnails to push notifications as well.
And thanks for the pointer on Pushover. I'll check it out to see if it can be a replacement for Google FCM.
A fully isolated setup on a dedicated network can certainly provide good privacy. A key benefit of Privastead is that it can send the videos to your smartphone remotely using a strong (MLS-based) end-to-end encryption.
The remote access part can be solved by wireguard or tailscale for less hands-on approach. Ntfy.sh/telegram/whatever cool kids use these days for notifications.
This and my previous comment probably amount to a full Dropbox comment now :)
Can you elaborate on the sending video part -- do you transfer the whole file or a link to the file on the server? Curious about the replication piece I mentioned
Privastead uses end-to-end encryption between the hub and the app. The hub encrypts the whole video file and sends it (through an untrusted server) to the app. The app will have a local copy of the video. The hub deletes the video upon delivery to the app. The server never has access to the unecrypted video.
I've been using locally hosted NVRs going on two decades now and so I definitely appreciate another local NVR option. But given the current lack of common requirements (e.g. more than 1 camera), curious if you're seeing any usage outside of your own? As others have mentioned Frigate is filling a nice gap for many, currently. I can only connect to it via a VPN I control and I can easily get notifications via Home Assistant.
I feel as though I have protection of getting the feeds to my phone securely, already. And while I'd love to be able to trust exposing Frigate and making it more accessible, I really don't have a need nor would I as the barrier to entry is already low enough to not impose much friction.
My intent isn't to dissuade you (obviously you wrote it for yourself) but I'd be curious if implementing a more secure transport in an existing OSS NVR that has traction was something you considered?
Your local setup plus VPN/wireguard is a good design. For me, port forwarding on my router was a no-go due to the increased attack surface. Therefore, I wanted to use the cloud to route the videos and hence I decided to use a strong end-to-end encryption scheme (MLS).
Regarding the limitation you mentioned: I plan to address them. The next task on my plate is to support multiple cameras. :-)
I actually don't do any port forwarding for my VPN. I end up back hauling over a public termination point on existing tunnels. All tunnels originate outbound in this manner.
FWIW, e2ee is a feature that mostly matters to me when I don't own the infrastructure, and my bytes are flowing over someone else's platform.
If I do own all the infra, it seems like a lot of extra effort and complexity in the application which could be farmed out to other solutions (I.e. wireguard).
That's right. My assumption is that the server is untrusted and that's why I use end-to-end encryption. This allows me to use any server, possibly even one operated by a third-party service in the future.
Push notifications are for notifying the apps of events (e.g., motion). The actual encrypted video (either motion-triggered video or livestreams) are transferred through the server.
If you use Home Assistant in an isolated local network with no Internet access, you will have good privacy. However, I needed to be able to use my camera remotely from my phone. That's when using strong end-to-end encryption becomes critical.
One option is to expose your instance to the Internet and using TLS/SSL to connect to it remotely. To me, that's risky since any machine exposed to the Internet is going to see more attack attempts and is harder to secure. The second option is to use their cloud. Here, they explain how remote access through their cloud works: https://www.nabucasa.com/config/remote/#security
They also mention its weaknesses:
"Before we talk about weaknesses, know that we will never abuse any weakness unless forced by a government entity. Our approach has one single weakness that is unavoidable: since we own the domain that hosts the remote connection, we are able to issue our own certificate and man-in-the-middle attack (MITM) remote connections. This would allow us to see all data passing through, including authentication tokens."
Privastead's use of MLS provides strong end-to-end encryption. And Privastead is not vulnerable to MITM attacks due to its secure pairing solution. I plan to write more about the security of Privastead including its pairing solution.
A third option is to set up a Wireguard service and expose the web UI only through the VPN. I use the Wireguard app to connect my phone to my VPN. This solution seems very safe to me. Are there risks I'm not thinking of?
That's definitely better, if done right. I still prefer to avoid port forwarding on my router if possible. The fewer attack surfaces I have to worry about, the better.
Right? All of this seems like trying to solve the wrong issue. Solve VPN routing with a routing solution, solve stream collection and processing with something like Frigate. I run ML models locally on a GPU and get a notification through MQTT/HA/Tailscale to my phone when the local stray cat arrives for dinner. What else do you really need?
I don't buy the cheap storage argument, trading an upfront cost of maybe $100 for all that complexity. And you can still keep archives - and even a reasonable UI - with some off the shelf FUSE driver. Or, less janky, a cron script running rclone or whatever.
Cool project, I just don't see people migrating to it.
Not yet. The server is currently fairly simple and doesn't do much other than relaying ciphertexts (and MLS group welcome messages). It should be okay serving one user and several cameras, but is certainly not scalable. I have plans to improve its scalability, but that is not at the top of the todo list. I'll check out Cloudflare workers for sure. Thanks.
I wasn’t actually thinking of scalability. I was thinking that Cloudflare’s Tunnel is a handy, and often free, way to make a LAN service available from outside, and the combination of Tunnel and Workers could make for a nice, easy to deploy, solution.
I'm not familiar with Scrypted unfortunately. But thanks for the pointer. I'll have to study it to understand its security and privacy implications. I skimmed the docs very quickly but couldn't find info on their use of encryption.
About HomeKit: yes, HomeKit uses iCloud end-to-end encryption (https://support.apple.com/en-us/102651) and is certainly superior to those systems that don't use encryption at all or just use encryption between the device and their servers. But Privastead has two advantages:
1) Privastead uses MLS for end-to-end encryption, which provides forward secrecy and post-compromise security. iCloud's end-to-end encryption does not. So what does that mean? This is from the link I included earlier:
"If you lose access to your account, only you can recover this data, using your device passcode or password, recovery contact, or recovery key."
If an attacker manages to access your password, recovery key, etc., they'll be able to decrypt all your videos (assuming they have recorded all your encrypted videos). Such an attack is not possible in MLS. Similar to the Signal protocol, MLS uses double ratchet and there is not a single password, recovery code, key, etc. that can decrypt everything.
2) The HomeKit framework and iCloud end-to-end encryption are not fully open source as far as I know. Therefore, we simply have to trust what Apple says about their security and privacy implications. That might be okay for some users, but not others. Privastead is and intends to remain fully open source. IMO, being open source is a critical component of any security/privacy solution that would like to gain users' trust.
Interesting. I think the usage model provided by Privastead is reliable enough (at least for me). I have access to my videos on my phone. If losing the phone is a concern (which should be rare), we can easily add a feature that keeps a copy of the files in the hub too.
I'm not too concerned with that. As far as I know, almost all Android apps that need to send notifications to the device use FCM. If Google pulls the plug on it, many apps will stop working as intended.
Sure, just wanted to tell you about it, as this seems to be defacto standard for foss android apps, for example most if not all https://matrix.org clients use it for push notifications (when you use their de googled build, or don't have play services) available. I also use a Signal fork with UnifiedPush and have some server alert scripts which post to my self-hosted ntfy instance, and the ntfy app itself will display them (otherwise for the Messengers, the Notifications will be from the messenger app itself, as these apps get "notified" aboout a notification and then do their own thing).
it's not about trusted/untrusted as in what will they do with the data. it's entirely about will the service be available long term or if theGoogs will deprecate it in the future.
I have no skin in the game of push notification infrastructure, but we've seen plenty of ShowHNs where a critical part of the Show is a total dependency on a 3rd party shim. While this isn't something like a dependency on a Twitter API that suddenly got yanked, it is still something that devs should really consider. Especially given theGoogs' track record.
Maybe this isn't the case it is a library deeply embedded in the Android ecosystem, but anytime a ShowHN mentions a dependency on theGoog it sets of the SpideySenses
The hub keeps a video until it is received by the app. The hub has a component called the delivery monitor, which processes acks from the app and keeps track of the delivery status of each video. It resends the videos when needed to ensure delivery. Once the app acks receipt of a video, the hub deletes it. The app then keeps all the videos until the user explicitly deletes them. (I've been thinking of a feature that automatically deletes all videos in the app that are older than a threshold, but haven't implemented it yet.)
The server is untrusted and does not have access to the plaintext of videos. It only receives the ciphertext (encrypted video) and notifies the app to download them. When the app fetches a video, the server deletes the ciphertext (in order to be memory efficient).
Yes, the hub is part of the Trusted Computing Base (TCB). That means that we trust it. If the attacker compromises it and takes full control of the hub, then the attacker has unfettered access to the IP camera.
That being said, if the attacker only manages to take a snapshot of the keys used by the hub for encryption (and nothing more), then the forward secrecy and post-compromise security aspects of MLS comes to our rescue. They ensure that the attacker can only decrypt some of the messages (at most a full video depending on what keys are compromised), but nothing before and after that.
The reason I chose Rust is that it eliminates memory safety vulnerabilities, which have been a major headache is software systems. Using Rust provides higher security assurance for the hub and the native library used in the Android app. Besides, OpenMLS is implemented in Rust, making it easy to integrate it with Privastead.
