Hacker News new | past | comments | ask | show | jobs | submit | arrdalan's comments login

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


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


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.


That didn't answer my question.


Sorry, which question did I miss?


The question of "What is the purpose of introducing the untrusted "server" component?". Looks like you've since replied to this, but it wasn't here or I didn't see it when I dropped the parent comment. The reply also doesn't compare alternatives such as direct use of an object store API. I've fielded a lot of user support questions about installation and would really hesitate to add that extra moving part if it's not strictly necessary.

Overall, we must be coming at this with quite different expectations of what a NVR should do. Not just this but also "when the app fetches a video, the server deletes the ciphertext (in order to be memory efficient)". Some installations of my NVR software are multi-user; I personally use it from multiple devices; etc. So the idea the whole pipeline exists just to transfer event videos to a single Android device results in a system that I would not find useful.

There certainly is space for different approaches. E.g. Frigate's approach is quite different than Moonfire NVR's but obviously is useful in a lot of ways to a lot of people. But my take is that Privastead's approach is going to be pretty niche, and the claim that other NVRs don't offer strong privacy assurance using "end-to-end" (on-prem server to client) encryption is untrue.

Also, I find it inaccurate to say it's mostly implemented in Rust which "provides higher security assurance for the hub". The Amcrest camera you've chosen is essentially developed by a hostile nation-state, and the protocol code you're using to interact with it (ffmpeg) is all written in C, which I find incongruous with the privacy/security goals. In fact, ffmpeg's RTSP and Matroska code is probably the majority of lines of code in the system.


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


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

Yeah. I'm also frustrated with cameras in general. I've commented on this a few times here before, [1] but tl;dr: I don't even know what camera I'd recommend even if I had the perfect open source firmware to flash onto it easily.

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

Okay, interesting, yeah that sounds like a significant step up for most folks.

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

Patches very welcome. It could use more attention than I've been able to give it recently but likely will interact well with your camera model as-is.

[1] https://news.ycombinator.com/item?id=37815064


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.


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.


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.


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)


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.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: