arrdalan

Our on-device AI is able to detect people, pets, and vehicles. We have tested people detection and it works well. We haven't really tested the other two.

Will do. Thanks for the suggestion.

ESP32: We haven't tested them. I would guess that they won't be able to handle the workload (on-device AI, encryption, and video encoding if there's no hardware encoder).

Ciphersuite: We use OpenMLS and we can choose any of the ciphersuites supported by it. We are using its post-quantum secure ciphersuite (MLS_256_XWING_CHACHA20POLY1305_SHA256_Ed25519).

There are two comments/questions here and I'll try to address them one by one.

Secluso vs. Frigate: I think you correctly mentioned some of the differences. We intend Secluso to be replacement for Ring-like WiFi cameras. Therefore, it needs to be easy to set up and use and provide similar functions to a Ring camera: the user plugs in the camera, opens the app, scan a QR code and perform a pairing process, and the camera is ready to use with its strong end-to-end encryption. The self-hosted version of Secluso requires a few more steps, but we've tried to automate it as much as possible. Home Assistant and Frigate are great platforms that are capable of providing good privacy (although they don't support advanced end-to-end encryption that Secluso does with forward secrecy and post-compromise security through MLS), but they require several steps, e.g., prepare/configure the IP camera, install and configure Frigate, integrate Frigate with Home Assistant, and configure remote viewing via cloud relay or VPN. Also, they are typically used with wired (Ethernet) IP cameras. WiFi IP cameras are possible but the RTSP stream between the camera and hub will be unencrypted, which might be vulnerable to eavesdropping.

Need for cloud relay: We have considered STUN and we are planning to deploy MLS over WebRTC for livestreaming (using the DAVE protocol) to improve the livestream performance. But this doesn't completely eliminate the need for a relay. If a STUN connection cannot be made due to some restrictions in one of the networks (that the camera and app are connected to), we will need to fall back to the relay. Also, if the phone is off/disconnected when an event video is recorded, we would like to transfer it (encrypted) to the relay ASAP in case something happens to the camera (e.g., it's taken by the intruder).

The videos are stored in the mobile app and you can view them when you need. The camera captures videos when it detects an event, e.g., a person, encrypts them, and sends them to the mobile app. The app decrypts them and stores them locally, allowing the user to view them when needed. The app also allows for livestreaming and it keeps the livestreamed video locally as well.

The camera_hub runs in the camera. It records videos, encrypts them, and sends them to the mobile app. The server is a relay in the cloud. It transfers encrypted videos from the camera to the mobile app.

One can use Frigate + Home Assistant + some secure remote access solution (e.g., VPN) to get a usage model similar to Secluso. Secluso however provides the following advantages:

1) You'll get advanced end-to-end encryption (MLS).

2) You'll get a trusted firmware (fully open source and verifiable software running on a Raspberry Pi). An important advantage of having trusted firmware is that you won't have to worry about putting a firewall in front of a camera that comes with closed source firmware and hence can't be trusted.

3) Secluso is easier to set up. All you need is to run our released binaries in a Raspberry Pi, a server, and then use our app. We are also open to providing server support for for a limited number of interested users. This will further simplify the setup. Please contact us if you're interested.

4) With Secluso, you won't need a hub or an NVR. All you need is a Raspberry Pi (and its camera).

There are several differences.

1) Usage model: RTSP cameras can be used for on-demand livestreaming. In contrast, the usage model of our camera is similar to a Ring camera: not only does it support livestreaming, but also it detects events (motion, person, pet, etc.), records a video clip, and sends it to the phone.

2) Connection and ease of use: with an RTSP camera, the camera acts as a sever. You can easily connect to it from your phone if your phone is connected to the same LAN. But if you're outside (which is very typical in the case of home security camera), you will need to connect to your LAN from outside. You have several options to achieve this (port forwarding, VPN, reverse proxy, etc.). Some of these options are not very secure. And they all require some non-trivial setup. In contrast, with our camera (again, similar to a Ring camera), the camera sends the videos to a cloud server and the app downloads them. Therefore, there's no need for the phone to access the LAN. (But note that in contrast to Ring, the videos in Secluso are always end-to-end encrypted. Ring supports an optional end-to-end encrypted mode, but you will lose advanced AI features such as person detection if you enable that since that is performed in their servers.) With the cloud-based video relay, we can then make it very easy to set up and use our camera. More specifically, our plug-and-play camera (https://secluso.com) is very easy to use: scan a QR code, pair, and you're good to go.

3) Encryption: Secluso uses MLS, which provides advanced end-to-end encryption features such as forward secrecy (per message) and post-compromise security.

4) Trust in firmware: Our goal with our recent Raspberry Pi camera is to provide a home security camera with a fully open source firmware. In fact, we now support a reproducible build, which allows you to verify that the firmware binary is built from the open source software in our github repo. This is in contrast to IP cameras that come with closed source firmware, making it difficult to assess their trustworthiness.

Yes, we have different approaches/designs. In fact, I don't even of think of Privastead as an NVR solution. The choice of using a hub is mainly because I didn't have control of the camera firmware. As I've mentioned in other comments, if I could, I'd move the hub logic to directly run inside the camera.

And my main comparison has been with security camera solutions that use their cloud solution to transfer videos (e.g., Ring). I think an open source solution that uses MLS and treats the cloud as fully untrusted is a superior alternative.

Regarding the multi-user support: yes, that's on the to-do list. A nice aspect of MLS is the notion of groups that it provides. In Privastead, each camera will have a separate MLS group and it could add multiple devices/smartphones to the group. The hub will then try to deliver the video to all devices in the group. Many aspects of the multi-user support still needs to be figured out, but it's technically feasible.

Regarding ffmpeg: I agree. I'm aware of it and I have it in my to-do list to replace that with a Rust-based implementation. In fact, I'll be looking into your retina library as one potential replacement. :-)

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)

Privastead/OpenMLS erases past keys from persistent storage in order not to suffer from the vulnerability you mentioned.

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.

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.

Sorry, which question did I miss?

This is a reasonable setup. We discussed it in other comments as well

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 haven't designed Privastead for continuous recording/streaming. It's mainly to receive motion/event-triggered videos and occasional live streaming. The usage model is more like Ring cameras.

The server only stores encrypted videos until they're fetched by the app. It can't decrypt the videos and hence is not meant as a storage space for decrypted videos.

That is correct. The goal is to be able to use the cloud to host the server without having to trust it. I personally use a cheap DigitalOcean VM.

Thanks for the pointers. Frigate, Home Assistant, and HomeKit were mentioned in other comments and we had some discussions there. They're certainly good setups.

A key design decision for me was using a strong end-to-end encryption scheme between the camera/hub and the app. MLS fit this need perfectly and therefore I came up with the design that is now Privastead.

I was also less concerned with supporting many cameras since all I needed was one camera inside my house. Rather, I wanted a lean solution that I could fully understand and reason about. I will however look more carefully into the NVRs you listed to see if I can borrow some ideas to support more cameras more easily in Privastead.

I did not, but I will. I would just point out that Privastead assumes the the push notification infrastructure is untrusted anyway.

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.

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.

Privastead relies on event detection by the camera itself. The Amcrest camera that I've used so far only does motion detection (which is all I needed on my end). There are IP cameras, however, that do human detection. I've purchased one of those and plan to integrate it, which would then allow Privastead to provide human detection too.

Using Pi's to run the hub is technically feasible (and I do plan on trying it on my end). Port forwarding is not needed. The Pi only needs to be able to initiate a connection to the server.

Google FCM is used for delivering notifications to the app. The server asks FCM to do so when needed.

The traffic is encrypted between the hub and the app. The camera is connected to the hub.

Yes, indeed. Using WebRTC and MLS together should provide good performance and privacy. In fact, Discord recently did that: https://discord.com/blog/meet-dave-e2ee-for-audio-video

It's something I plan to look into at some point.

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.

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. :-)

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.