Self-Hosted CCTV (IP Home Security Camera) System

Does Privacy Guides have a recommendation for a secure & private system for security cameras for a home or office?

I originally asked this question on the Security Stack Exchange

My biggest concern above was: if you’re running an ethernet cable to a wired IP camera outside your house, what’s to prevent an attacker from plugging in their own battery-powered raspberry pi or packet squirrel (dropbox) into the exposed etherent plug, and then getting on your network, able to see the feed from all of your cameras?

Obviously the camera ethernet network would need to be isolated from the main network. And, if possible, that network wouldn’t have internet access. But, still, an attacker outside the house would be able to see “through” all of the cameras – unless that transmission was encrypted.

And that brought me here: is there a solid self-hosted security camera solution where all of the traffic between the cameras and the local storage server is securely encrypted?

What does Privacy Guides recommend for a self-hosted security camera system?

Update: the solution should be FOSS, and the documentation on how the encryption works should be thorough and configurable. I’m not trusting some company’s proprietary encryption.

Update 2: I don’t trust X.509, so hopefully just relying on TLS can be avoided – unless it’s trivial and durable to force-pin the public key that the camera’s encrypt-to

2 Likes

Ease of physical access, with the primary security mitigation being the camera height installation.

1 Like

You can check out Zoneminder or Camera.ui, as for those products, encryption between the camera and the controller, you’ll need to check the documentation. Personally, I went with Unifi, an IPFire box (I went with IPFire because it’s stupid easy to set up), and a switch that feeds my cameras, along with a VLAN with inter-VLAN rule sets. My cameras are pretty high up, and the one that isn’t is behind a tall green rose bush that isn’t visible, and I turned off the status light on it.

https://zoneminder.com/

1 Like

I have been using this setup for years.

Accessible only via hidden service (Tor + client authorisation)

1 Like

Hello @maltfield! I wanted to take a moment to introduce our project, Secluso.

We envision Secluso as a drop-in replacement for easy-to-use home security cameras such as Ring. The main difference, however, is that Secluso provides strong privacy guarantees. It leverages MLS (Messaging Layer Security), which is a state-of-the-art end-to-end encryption protocol with strong cryptographic guarantees such as forward secrecy and post-compromise security. Using the MLS protocol, Secluso cameras encrypt videos before sending them to the Secluso mobile app via the cloud; hence no one other than the user, not even us, can view these videos. Moreover, our software is fully open source and verifiable. That is, the user can verify that the software running in their camera is the same software that we have made open source. We believe that being open source and verifiable is a critical feature for any security and privacy solution, especially a home security camera. Otherwise, there’s no way a user can be sure that their cameras do not secretly leak their videos.

Importantly, this design also addresses the threat model you described. Even if an attacker were to gain physical access and plug into the camera network, they would not be able to decrypt or view any video streams, because encryption happens at the application layer before transmission. Secluso does not rely solely on transport-layer security. Instead, encryption and authentication are enforced end-to-end using MLS keys controlled by the user’s devices.

We plan to soon take pre-orders for a limited number of our cameras and will be sending out updates on this in a few weeks via the mailing list on our website (https://secluso.com).

You are also more than welcome to use your own Raspberry Pi or IP camera with our existing software. Detailed setup instructions and more information are available on our GitHub here: GitHub - secluso/secluso: A privacy-preserving home security camera that uses end-to-end encryption. (Secluso was previously named Privastead.)

Please let me know if you have any questions about this! We’d be more than happy to help. We’re also available at secluso@proton.me.

4 Likes

@jkaczman thanks for your input :slight_smile: I have a few questions about your solution

It leverages MLS (Messaging Layer Security), which is a state-of-the-art end-to-end encryption protocol with strong cryptographic guarantees such as forward secrecy

PFS on a stream of video? Interesting. How often do the keys change?

encryption and authentication are enforced end-to-end using MLS keys controlled by the user’s devices.

What does the PKI look like? Can I pin to a single certificate (public key)?

You are also more than welcome to use your own Raspberry Pi or IP camera with our existing software

Are there any other commercially-available options that support MLS?

Seems like the common encrypted standards for IP cameras are RTSPS and ONVIF. Why did you choose MLS? Why is your encryption better than the most popular open standards?

2 Likes

This seems like your first and biggest problem lol

Beyond that, I’d basically just do a VLAN per camera. I honestly might be more concerned about an attacker (or lightning strike) taking everything down with a power surge, so making this network electrically separated from the rest of the network would be a priority for me.

2 Likes

If your cameras are powered by PoE, that sounds like a UPS with surge protection feature would do the trick.

2 Likes

@maltfield Thanks for the thoughtful questions.

Fristly, I misspoke in my previous message: for this threat model, we recommend using the Raspberry Pi setup, because in current IP-camera mode there is an unencrypted camera-to-hub stream before Secluso’s encryption is applied.

1. “PFS on a stream of video? How often do keys change?”

In our design, video is chunked and each chunk is encrypted as an MLS application message. So message keys ratchet forward per message (not one static key per stream).

On top of that, we force fresh epoch updates (MLS self-update commits) at session boundaries (every new motion video, every new livestream session, and every thumbnail)

For motion/thumbnail, the commit is included at the start of the encrypted file. For livestream, commit data is sent as chunk 0 before media chunks.

The app also sends self-update proposals on heartbeat (on app launch and every ~6 hours), and the camera merges those in subsequent commits. These periodic MLS self-updates let us re-key away from a stolen state snapshot, so a temporary compromise doesn’t keep exposing future video.

2. “What does the PKI look like? Can I pin one cert/public key?”

There are two different trust/auth planes.

Plane A (camera ↔ app MLS auth):

We do not use Web PKI/X.509 as the trust anchor here. Pairing is authenticated with a high-entropy shared secret delivered via local QR scan which is injected as an MLS external PSK. If the secret is wrong, join fails. We also verify expected inviter/invitee identities in-group. So this plane is PSK-anchored MLS auth not CA-chain auth.

Plane B (transport to delivery server):

This is standard HTTP(S) client/server transport. We recommend HTTPS (typically via reverse proxy). The media itself remains MLS end-to-end ciphertext even if server is untrusted. Currently, the app/hub settings do not include an option to pin a specific server certificate or public key.

3. “Any other commercial options that support MLS?”

We are not aware of mainstream commercial camera systems using MLS today. If you ever come across one, we’d love to hear about it.

4. “Why MLS instead of RTSPS/ONVIF?”

ONVIF is mainly control-plane standardization. It is not equivalent to end-to-end encrypted media semantics. RTSPS gives hop security (TLS on that transport hop) but any relay can decrypt. MLS gives app-layer end-to-end encryption semantics over an untrusted relay, plus forward secrecy and post-compromise recovery via explicit group state evolution (RFC 9420).

3 Likes

Not necessarily for other Ethernet devices connected to the same switch. I’d want the camera switch or anything else outdoors to be connected to the rest of my network via fiber probably. I ran fiber to my detached garage for this reason for example :slight_smile:

1 Like