An open source privacy-preserving home security camera using end-to-end encryption

General Project Showcase
1

Hi everyone,

We would like to introduce Secluso, a privacy-preserving home security camera solution, which uses end-to-end encryption. Secluso tries to provide functionality similar to a Ring or a Blink camera, but without violating the user privacy (as most mainstream consumer cameras do!) The functionality includes sending video recordings to the app when the camera detects an event (motion, person, pet, etc.) as well as on-demand live-streaming. To detect events, Secluso performs AI on the camera feed fully locally (i.e., on the camera).

Existing home security cameras have a terrible privacy track record. For example, according to FTC, Ring employees and contractors illegally accessed users’ videos (source). Eufy was fined $450,000 after New York’s Attorney General found its “local only” and “end-to-end encryption” claims were false (source). And Wyze says that a breach allowed 13,000 camera users to see inside other users’ homes (source). Not to mention, majority of these companies don’t encrypt videos from their cameras, so they’re able to view them whenever they want. We think we can do better than this!

Guaranteeing user privacy has been and will continue to be the number one design principle in Secluso! To that end, Secluso uses the following techniques. First, all videos are end-to-end encrypted from the camera to the mobile app (Android or iOS). The encrypted videos are transferred via a cloud server, but the server is untrusted and cannot decrypt the videos. Secluso uses the Messaging Layer Security (MLS) for end-to-end encryption, which provides advanced features including forward secrecy and post-compromise security. At a high level, these features guarantee that even if the camera or the app are ever compromised and encryption keys are stolen, the compromised keys cannot be used to decrypt videos from the past and future. Second, Secluso is fully open source (and will always remain open source), and hence can be inspected by users and security experts. Third, Secluso’s camera firmware and part of its mobile app are implemented in Rust, which eliminates memory safety vulnerabilities. Fourth, Secluso supports reproducible builds, which allows users and experts to verify that the binaries inside the camera firmware are compiled from our open source code on Github. Finally, we are planning to add immutable and transparent firmware updates, which guarantees that all automatic updates to the camera firmware will be transparent to the public and immutable for one year. This will prevent malicious and silent updates to our cameras.

A little bit about us (the project founders): Ardalan is a computer science professor with expertise in computer security and privacy. John is an open source and privacy enthusiast that has over a decade of experience in software development. Ardalan initially started this project since he needed a security camera for inside his house but did not want to jeopardize the privacy of his family. John later discovered this project on Github since he was disappointed after looking around and learning that there wasn’t any cameras on the market that were privacy preserving. They then joined forces and have been working together since the beginning of this year. They’ve been both working on it in their spare time and have put in a lot of energy to make sure it’s secure and functional.

Now, we would like to ask you to help us by using our solution and giving us feedback. There are several ways you can try our camera solution:

  • Fully self-hosted: You can use our software on your own camera hardware and server. For the camera, you can either use a Raspberry Pi (even one as weak as a Raspberry Pi Zero 2W) or an IP camera that supports RTSP. In the case of Raspberry Pi, our camera software runs directly on the Pi. With IP cameras, our software runs on another machine connected to the camera and acts as a hub (and a firewall since we can’t trust IP cameras with closed source firmware). You also need a server with a public IP address. We have detailed instructions in our Github repository on how to set up this self-hosted option. If you run into any issues, let us know (either here, on Github, or via email at secluso@proton.me) and we will be more than happy to help you fix them.

  • Semi self-hosted: If you have your own camera, but don’t have a server, we can try to help with that. We can try to accommodate a limited number of users in our own server instance (for free). Just send us an email if that’s what you would like to do.

  • Plug-and-play camera: We have also been building a plug-and-play camera using a Raspberry Pi Zero 2W and a 3D-printed case that we have designed in house. The goal of this camera is to make it as easy as a Ring camera for a user to use it. When you get our plug-and-play camera, you simply pair it with our app and you’re good to go. (But note that you can still verify all the software running on the Pi if you’d like to.) If you’re interested in this option, please go to our website (htttps://secluso.com) and join the waiting list. We plan to hand build a limited number of our early prototype camera and giving them for free to interested users and get their feedback. When they are ready (in a few months), we will email the waiting list and ask for volunteers to try our plug-and-play camera. By joining the waiting list, you also help us gauge the community’s interest in our plug-and-play camera. If we see interest from the community, we will look into scaling up our camera production and we will email the waiting list with information on how to acquire one when the cameras are ready. We’re hoping that our plug-and-play camera can provide an easy-to-use privacy-preserving home security camera for all privacy-conscious people (and beyond) as there is currently no such camera out there.

Even if you can’t use our camera, we ask that you share with us your thoughts. Do you have a use for a privacy-preserving home security camera? Are there any important features that you need but we currently don’t support? Any other suggestions?

Your help and feedback will go a long way in helping us improve Secluso and will motivate us to invest even more energy into it and hopefully turn it into a camera that can support a large number of users in the future.

Finally, if you’re interested to hear more from us regarding our efforts, please go to our website (https://secluso.com) and join the mailing list by clicking on the “Keep in touch” button.

Our Github repository: GitHub - secluso/secluso: A privacy-preserving home security camera that uses end-to-end encryption. (Secluso was previously named Privastead.)

Our website: https://secluso.com

15 Likes
Security camera setup for beginners?
Best Home Security Cameras Expert Advice
2

I would love to see you make a demo video and a tutorial showing all three options for tech savvy (non technical) users to feel comfortable using it and providing feedback so you may keep improving it.

Please see to this if you can. It would be a massive step toward actually showing what’s what and making those who have never used security cameras feel at ease.

6 Likes
3

Additionally, documentation and other similar info would be an added benefit.

I do suspect however the best option for most is still going to be the easy route most want - to buy the camera and have it be a one to two click install of your software be installed. The issue I imagine here is no vendor allowing users to remove their software and use it as they want with another software. The home security camera industry was born enshittified.

So, hope development continues at a brisk pace so we don’t have to wait for years for your camera’s (albeit I know such things do take time). My impatience stems from this space not having any private solution worth using.

4 Likes
4

Thanks for the thoughtful feedback, we really appreciate it!

We already have some documentation on our GitHub today, but it’s definitely more geared toward technical users and could be improved. Making it easier to follow, along with putting out a demo/tutorial video that walks through all options so people who aren’t technical can still feel comfortable using it, is a top priority for us.

For the “one–two click” setup, we agree that most people will want that simplicity, and that’s exactly what we’re aiming for with the plug-and-play version.

We also share your impatience. This space has gone far too long without a private alternative. While careful development takes time, we’re making steady progress and will continue sharing updates as we reach each milestone.

5 Likes
5

Best of luck. Right now I’m using Reolink, which I believe is relatively private bc I’m not using their cloud. If the hardware is top notch, and your software is secure, I would consider it an option for me.

1 Like
6

That’s awesome, and thanks for sharing what you’re using. As an extra precaution, in case you’re not already, it can help to block outside network access (even though you’re not using their cloud) for the cameras and NVR with a firewall. With closed firmware you don’t always know what services or traffic might be running in the background, so it’s a simple way to add a bit more peace of mind.

2 Likes
7

I poked around just checking basic stuff and I stumbled upon this

I don’t really program Rust but it would appear that you’re doing == comparison for the stored password. Please let me know if this is indeed hashed strings that are being compared, but if that’s not the case, you’re doing this terribly wrong:

The == comparison tends to exit the instant it finds a letter that doesn’t match. This allows timing attacks that leak the password in O(n) time. Here’s a nice explanation: Timing Attacks against String Comparison in python

You definitely don’t want to store passwords in plaintext. Always use Argon2 or scrypt to store passwords on server.

Even if you’re comparing an Argon2 hash, the timing attack leaks the hash in O(n) time that can then be brute forced locally. Argon2 is memory hard but servers don’t usually allocate gigabytes of memory per login operation so it parallelizes decently.

5 Likes
8

Thanks for pointing this out. You’re right that we missed it. I just pushed a fix to do a constant-time comparison. These passwords are not user generated. They’re tokens generated by our configuration tool and have a constant length. I think it’s still useful to hash them to prevent against a leak of passwords from the server. We’ll add that as well.

Just note that the server in Secluso is fully untrusted. Therefore, this does not impact the confidentiality of videos, which are end-to-end encrypted. We just added a super simple HTTP basic authentication to prevent easy access to our server. But we plan to replace this with a better auth solution in the future such as OAuth.

9

Hi @maqp, we really appreciate you taking the time to review some of our code.

Adding on to @ardalan, here’s a bit of an explanation of how credentials work in Secluso:

  • The username and password fields are not human-chosen. They’re long, randomly generated tokens and only used for server authentication. The username itself is a random string and is used as the key into a HashMap on the server.
  • That means the server first checks against the user hash map, so without guessing a valid random username you never reach the password comparison. To impersonate a user, an attacker has to guess a valid username and the matching password.
  • With 14 random characters each for username and password (28 total) drawn from the 91-character alphabet used by our generate_random() function, the combined entropy is about 182 bits (~91 bits per token). That space is effectively unbrute-forceable in any realistic scenario. The real risk of anything happening would be local compromise of the device file containing the tokens.
  • Crucially: our threat model treats the server as untrusted, we never hand it encryption keys, raw plaintext, or any metadata that would let it decrypt or link data to a user. It only ever sees encrypted blobs and the tokens needed to authorize storage uploads/fetches.

I would also like to note that the current server is intentionally lightweight and meant for self-hosting a small number of cameras. We plan to develop a separate server codebase designed for multi-user deployments, with additional focus on scaling and multi-tenant security.

1 Like
10

Are you also planning to release hardware like video doorbells to compete with e.g. Ring?

I think it’s a very exciting project, especially as the code is open source. Who knows if Ring’s E2EE is not backdoored. (You already posted the link about Eufy’s E2EE being a lie.)

3 Likes
11

Considering it is Ring and their reputation, it’s safe to assume to is not quite E2EE.

4 Likes
12

Yeah it’s a good idea to create a hashmap for users first and then check if the username is on the list. That’s an O(1) operation.

The users won’t necessarily treat the username as a secret, please don’t count that towards the authentication entropy. That being said 91 bits is mostly fine for password entropy. It’s a bit on the lower end for 2025 for state actors but I’m guessing that’s not part of the threat model. You absolutely do not need 91 bit username space. I mean, IPv6 is 64 bits. The code shows you’re adding some rate limiting which is fine. But ultimately I’d focus on just generating a 128-bit or 256-bit password so you and your users can cross that from the list of things to worry, and like @ardalan said, getting the password hashing deployed.

The thing is, even if it’s mostly fine in practice, these are the things security conscious people check first, and if the best practices are replaced with custom low-level primitives (even good quality ones like subtle), it will raise eyebrows. So please try to see the best practices like Argon2 as a selling point. Most privacy conscious people will want to see what the building blocks are, without checking what MLS entail. So if you find the time, please add an info-box that mentions the primitives. I’m putting best practices in parenthesis

  • RNG (kernel CSPRNG)
  • Protocol (MLS)
  • Password hashing method (Argon2id)
6 Likes
13

A very promising initiative! A few questions:

  • For the IP camera route, what type of machine were you imagining it being connected to? When I’m out of the house, especially for more than a few hours, I shut down my laptop so that the disk encryption is in full effect.

  • For the standalone camera route, I could set up the Raspberry Pi, but doing maintaining a server would be over my head. Do you intend to make your server service available to future users, beyond just beta testers?

  • For the plug-and-play camera route, it looks like you plan to mitigate the risk of mail interception by enabling the firmware to be verified? Do you have a sense of the timeline on this offering?

  • For the Android app, I highly recommend making it available through the Accrescent app store, which is available by default on the GrapheneOS app store.

3 Likes
14

Hi @Regime6045 and @whistlesilent, thank you both for your interest and questions. Please see my replies below.

Doorbell Cameras: We have not discussed this yet. Right now, our focus is on indoor cameras first, as they raise the most pressing privacy concerns. It is likely we will branch out into other hardware such as video doorbells eventually, but we don’t have a time estimate for this unfortunately.

IP camera machine: The type of machine doesn’t matter as long as it’s available 24/7 (or however long you’d like the cameras to be working for). Since you mentioned shutting down your laptop for full disk encryption, a Raspberry Pi or low-power server would be a great alternative, and would be capable of acting as a hub for multiple cameras.

Server availability: Right now, we don’t have the resources to host the server for everyone, though it’s likely we will offer this service in the future. In the meantime, our focus is on making it effortless for you to run your own. Our update coming soon will make this extremely simple. All it will require is running a script on your computer: it’ll prompt you to enter your server IP and credentials, and then it will automatically handle installation, updates, and configuration on the server. Another script like that will be available for Raspberry Pi, so once your hardware is ready, you can be up and running in under 5 minutes without needing any technical knowledge.

Mail interception: We’re currently exploring many different options for this. I’m not sure of a timeline yet, but I’d be happy to update you when we have this figured out better.

Android app: Thank you for the suggestion! Our apps aren’t officially published anywhere yet and currently need to be built manually. We plan to publish everywhere in the coming weeks (at the same time as the scripts I mentioned above). Among the iOS and Google Play store, we plan to publish in Accrescent as well!

5 Likes
15

Great project. Design-wise, please consider adding a text like “E2EE”, maybe in a funny way. To let people know their faces aren’t going to some Big Tech cloud.

16

Definitely support your project.

I wonder if there is any comparison to BlueIris software. It has been a go-to for standalone home/business IP Camera security and has a long track record.
The only negative I think is that it might not be open-source.

17

I have been waiting for this and would pay for it. Not very technical, so user setup guides will be required for me. Looking forward to see how this evolves!

5 Likes