- Secluso ist ein persönliches DIY-Heimüberwachungskamerasystem auf Raspberry-Pi-Basis, mit dem sich Livebilder, Benachrichtigungen und Aufzeichnungen auf dem Smartphone ansehen lassen, ohne das Videomaterial an einen Cloud-Anbieter zu übergeben
- Der Fernzugriff unterstützt Ende-zu-Ende-Verschlüsselung; auf dem üblichen Einrichtungsweg übernimmt Secluso Deploy Image-Build, Pairing und Relay-Konfiguration und zielt auf eine Einrichtung in 5 Minuten ab
- Unterstützte Hardware sind Raspberry Pi Zero 2W, Raspberry Pi Camera Module V1/V2 oder Kameras auf Basis der Sony-Sensoren OV5647 bzw. IMX219, Android oder iPhone sowie ein Linux-VPS-Relay-Konto oder kostenloses Beta-Relay-Hosting zum Testen
- Das Deployment erfolgt, indem in ein vorgefertigtes Secluso OS-Image eindeutige Zugangsdaten injiziert werden, die auf der Maschine des Nutzers erzeugt wurden; bereitgestellt werden reproduzierbare Builds der Runtime-Binärdateien, des Deployment-Tools, der Android-App und von Secluso OS
- Das Sicherheitsmodell umfasst ein nicht vertrauenswürdiges Relay-Design, Forward Secrecy und Post-Compromise Security; gleichzeitig ist die Prüfung lokaler Gesetze zur Nutzung von Verschlüsselung erforderlich, und die Verantwortung liegt beim Nutzer
Was Secluso bietet
- Secluso ist ein privates Heimüberwachungskamerasystem für Raspberry Pi
- Nutzer können auf dem Smartphone folgende Funktionen verwenden
- Livebilder ansehen
- Benachrichtigungen erhalten
- Aufzeichnungen öffnen
- Ziel ist es, aus der Ferne auf Heimüberwachungsvideos zuzugreifen, ohne sie einem Cloud-Anbieter anzuvertrauen
- Das Projekt wird von Secluso, Inc. entwickelt; als Mitgründer werden Ardalan Amiri Sani und John Kaczman genannt
Hauptfunktionen
-
Ende-zu-Ende-verschlüsselter Fernzugriff
- Unterstützt den Zugriff auf Livebilder, Benachrichtigungen und Aufzeichnungen vom Smartphone aus
-
Einrichtung in 5 Minuten
- Auf dem typischen Einrichtungsweg übernimmt Secluso Deploy den Image-Build, das Pairing und die Relay-Konfiguration
-
Open Source
- Der Code kann geprüft, selbst gehostet und mit Beiträgen erweitert werden
-
Vollständig reproduzierbare Releases
- Auf Basis des öffentlich verfügbaren Quellcodes lassen sich Runtime-Binärdateien, Deployment-Tool, Android-Mobile-App und Secluso OS verifizieren
Anforderungen
-
Raspberry Pi
- Raspberry Pi Zero 2W
-
Kamera
- Raspberry Pi Camera Module V1 oder V2
- oder Kameras auf Basis der Sony-Sensoren OV5647 bzw. IMX219
-
Relay
- Linux-VPS-Login des Nutzers
- oder eine E-Mail mit der Bitte um kostenloses Beta-Relay-Hosting für Tests
-
Smartphone
- Android oder iPhone für Pairing, Benachrichtigungen und Wiedergabe
Schneller Einrichtungsablauf
- Secluso Deploy aus dem neuesten Release herunterladen
- Lokal ein personalisiertes Secluso OS Image und einen geheimen QR-Code für die Kamera erzeugen
- Secluso Deploy das eigene Relay per SSH provisionieren lassen oder kostenloses Beta-Relay-Hosting zum Testen per E-Mail anfragen
- Raspberry Pi starten und in der Mobile-App pairen
- Falls Hilfe bei der Auswahl von Hardware oder VPS nötig ist, bietet der Leitfaden Build Your Own Guide Hardware-Vorschläge und einen einfachen Einstiegspfad
Mobile-App
- Nach der Einrichtung lassen sich mit der Mobile-App Fernzugriff, die Prüfung aktueller Ereignisse und das Öffnen verschlüsselter Clips nutzen
- Links zur Mobile-App
Sicherheit und reproduzierbare Builds
- Das Sicherheitsmodell umfasst ein nicht vertrauenswürdiges Relay-Design, Forward Secrecy und Post-Compromise Security
- Informationen zum Melden von Schwachstellen finden sich in SECURITY.md
- Das Projekt verteilt mit Secluso OS ein vorgefertigtes Raspberry-Pi-Image
- Secluso Deploy erzeugt auf der Maschine des Nutzers eindeutige Zugangsdaten und injiziert sie in das vorgefertigte Image
- Secluso OS, Deployment-Tool, Runtime-Binärdateien und Android-App sind vollständig reproduzierbar
- Verifizierungsmaterial findet sich hier
- releases/README.md: Reproduzierbarkeitsprüfer für Binärdateien und Deployment-Tool
- mobile_client/tool/repro/README.md: Reproduzierbarkeitsprüfer für die Android-Mobile-App
- os/README.md: Reproduzierbarkeitsprüfer für Secluso OS
- Das Image sollte geprüft werden, bevor es vom Deployment-Tool verändert wird, und direkt aus den Releases heruntergeladen werden
Beiträge und Hinweise
- Fragen und Beiträge sind willkommen; Beiträge erfolgen gemäß der Projektlizenz
- Kontakt: secluso@proton.me
- Dieses Projekt verwendet Verschlüsselung, daher sollten vor der Nutzung die lokalen Gesetze geprüft werden
- Die Nutzung erfolgt in eigener Verantwortung; die Projektautoren geben keine Garantien in Bezug auf Datenschutz oder Heimsicherheit
1 Kommentare
Meinungen auf Hacker News
Wirklich ein großartiges Projekt. Aus den oben genannten Gründen habe ich zu Hause keine Überwachungskameras installiert, aber das bringt mich zum Umdenken.
In Kombination mit der Open-Source-Firmware https://github.com/openmiko/openmiko dürfte das für datenschutzbewusste Menschen eine starke Kombination sein.
Dann bräuchte man keinen separaten Rechner als Hub, was die Einrichtung deutlich einfacher machen würde.
Falls ihr ein Open-Source-Hardware- und Firmware-Design für eine Kamera mit Bewegungssensor braucht, hier ist eines:
https://github.com/maxlab-io/tokay-lite-pcb
Kaufen kann man es auch:
https://www.mouser.ca/ProductDetail/Maxlab/TOKAY-LITE-01?qs=...
Alle proprietären Produkte, die ich gesehen habe, setzen Blende/Belichtung anhand der durchschnittlichen Belichtung des Frames, sodass das Kennzeichen als komplett weißes Rechteck erscheint.
Bei Nachtaufnahmen müsste es helle und dunkle Belichtungen durchprobieren.
Wenn man mit KEM[1] eine Struktur wie sealed_box[2] baut, lässt sich die Privatsphäre selbst dann schützen, wenn die Kamerahardware physisch beschlagnahmt wird.
Mit ML-KEM, also Kyber, zusammen mit McEliece-KEM, ECDH oder RSA-KEM kann man auch Post-Quanten-Resistenz bieten.
In so einem System ist ein traditioneller symmetrischer Schlüsselansatz zwar an sich ebenfalls quantenresistent, aber die Kamerahardware besitzt einen langfristigen symmetrischen Schlüssel, der nach einer Beschlagnahmung extrahiert werden könnte.
Ein Ratchet-Mechanismus, der den Schlüssel in regelmäßigen Abständen hasht, kann helfen, hat aber keine Selbstheilung, und es besteht das Risiko, dass frühere Schlüssel aus persistentem Speicher wiederhergestellt werden.
[1] <https://en.wikipedia.org/wiki/Key_encapsulation_mechanism>
[2] <https://libsodium.gitbook.io/doc/public-key_cryptography/sea...>
Vor ein paar Jahren wollte ich ein selbstsouveränes Home-Security-System für ganze Communities und HOAs bauen. Ich habe mit IBM-Ingenieuren darüber gesprochen, Videos in der Nähe der Geräte mit Machine-Learning-Modellen zu scannen.
Ich kaufte Kameras mit RTMP und RTSP und schickte sie an Entwickler; danach war es nicht schwer, per WebRTC irgendwohin zu streamen. WebRTC hat Ende-zu-Ende-Verschlüsselung.
Mein Anwendungsfall war allerdings, verschlüsselte Videos aufzubewahren, mit einem anderen Schlüssel pro Minute und pro Kamera, und das Entschlüsselungsprotokoll musste klar definiert sein.
Ich sehe das Sicherheitsproblem nicht nur an einem Ende, also beim Aufzeichnen von Verbrechen, sondern auch am anderen Ende, also bei Massenüberwachung und der Frage „Wer überwacht die Überwacher?“.
Einen längeren Beitrag gibt es hier: https://community.qbix.com/t/balancing-privacy-and-accountab...
Wenn jemand gemeinsam ein Startup aufbauen möchte, das an Hausbesitzer und Gated Communities verkauft, kann er Greg unter der Domain qbix.com kontaktieren.
Bei Ende-zu-Ende-Verschlüsselung würde ich verstehen, dass der Traffic zwischen Kamera und App verschlüsselt ist, aber tatsächlich ist das nicht der Fall.
Dafür müsste die App in der Kamera das System unterstützen, und bei vielen Kameras wäre das zwar möglich.
Besonders dann, wenn man den Kontext unzuverlässiger Server und Benachrichtigungsdienste hinzunimmt.
Ich packe alle nicht vertrauenswürdigen Geräte, einschließlich Kameras, in ein VLAN ohne Internetzugang; vom Haupt-VLAN aus sind sie erreichbar, aber in die Gegenrichtung ist es blockiert.
Im Haupt-VLAN laufen Frigate und Home Assistant, die sich mit den Kameras verbinden. Von außerhalb des Hauses verbinde ich mich per WireGuard.
Ich frage mich, welchen Zweck die nicht vertrauenswürdige „Server“-Komponente hat. Soll sie an einem anderen Ort als dem vertrauenswürdigen „Kamera-Hub“ laufen, zum Beispiel auf einem Cloud-Server?
Das ist zentral für Privasteads Behauptung, in Sachen Datenschutz besser zu sein als andere Lösungen, wird aber nicht erklärt.
Mein NVR [1] nutzt nur einen vertrauenswürdigen Server, der sich im selben Gebäude wie die Kameras befindet. Auch ich empfehle, Kameras keinen Internetzugang zu geben, weil proprietäre Software in Bezug auf Datenschutz und Sicherheit meist ein kompletter Albtraum ist.
[1] https://github.com/scottlamb/moonfire-nvr
Ich persönlich verwende eine günstige DigitalOcean-VM.
Interessant ist der Teil, wonach „garantiert wird, dass nur Hub und Mobile-App Zugriff auf unverschlüsseltes Video haben“.
Mit Blick auf die Rust-Implementierung von OpenMLS, sichere Ende-zu-Ende-Speicherung und TLS-Vektoren entfällt der Bedarf an sicherem Tunneling, wenn ein DIY-Home-Camera-Setup über den Privastead-Hub mit dem Internet verbunden ist.
Es scheint auch möglich, hier Gesichtserkennung und Echtzeit-Monitoring einzubauen.
Wer schon einmal Eigenfaces gesehen hat, bekommt den Eindruck, dass sie wie frühe Menschen aussehen. Ein Ansatz ist die Hauptkomponentenanalyse (PCA), die aus mit den wesentlichsten Gesichtsmerkmalen verbundenem Rauschen die wichtigsten Eigenschaften menschlicher Gesichter herauslöst.
Da der Fokus stark auf Sicherheit liegt, könnte auch interessant sein, dass es Kameras mit Secure Boot gibt. Soweit ich weiß, ist Axis einer der Hersteller, die sich auf diese Funktion konzentrieren.