Privastead - Sistema open source de cámaras de seguridad para el hogar personal (con soporte de cifrado de extremo a extremo)
(github.com/privastead)- Secluso es un sistema DIY de cámaras de seguridad para el hogar personal basado en Raspberry Pi, que permite ver video en vivo, notificaciones y grabaciones desde el teléfono sin entregar las imágenes a un proveedor de nube
- El acceso remoto soporta cifrado de extremo a extremo y, en la ruta de configuración habitual, Secluso Deploy se encarga de la compilación de la imagen, el emparejamiento y la configuración del relé, con el objetivo de configurarlo en 5 minutos
- El hardware compatible incluye Raspberry Pi Zero 2W, Raspberry Pi Camera Module V1/V2 o cámaras basadas en sensores Sony OV5647·IMX219, Android o iPhone, una cuenta de relé en un VPS Linux o hosting gratuito de relé beta para pruebas
- El método de despliegue inyecta credenciales únicas generadas en la máquina del usuario en una imagen precompilada de Secluso OS, y ofrece builds reproducibles para los binarios de runtime, la herramienta de despliegue, la app de Android y Secluso OS
- El modelo de seguridad incluye diseño de relé no confiable, secreto hacia adelante y seguridad posterior a la intrusión, pero requiere verificar las leyes locales sobre el uso de cifrado y queda bajo responsabilidad del usuario
Qué ofrece Secluso
- Secluso es un sistema de cámaras de seguridad para el hogar personal para Raspberry Pi
- El usuario puede usar las siguientes funciones desde el teléfono
- Ver video en vivo
- Recibir notificaciones
- Abrir grabaciones
- El objetivo es acceder de forma remota a los videos de seguridad del hogar sin confiarlos a un proveedor de nube
- El proyecto es desarrollado por Secluso, Inc., y se mencionan como cofundadores Ardalan Amiri Sani y John Kaczman
Funciones principales
-
Acceso remoto con cifrado de extremo a extremo
- Permite acceder desde el teléfono a video en vivo, notificaciones y grabaciones
-
Configuración en 5 minutos
- En la ruta de configuración habitual, Secluso Deploy se encarga de la compilación de la imagen, el emparejamiento y la configuración del relé
-
Open source
- Puedes inspeccionar el código, hacer self-hosting y contribuir
-
Releases completamente reproducibles
- Permite verificar, a partir del código fuente público, los binarios de runtime, la herramienta de despliegue, la app móvil de Android y Secluso OS
Requisitos
-
Raspberry Pi
- Raspberry Pi Zero 2W
-
Cámara
- Raspberry Pi Camera Module V1 o V2
- O una cámara basada en sensores Sony OV5647·IMX219
-
Relé
- Login de un VPS Linux del usuario
- O un correo para solicitar hosting gratuito de relé beta durante las pruebas
-
Teléfono
- Android o iPhone para emparejamiento, notificaciones y reproducción
Flujo de configuración rápida
- Descargar Secluso Deploy desde la release más reciente
- Generar localmente una imagen personalizada de Secluso OS y un código QR secreto de la cámara
- Hacer que Secluso Deploy aprovisione el relé del usuario por SSH, o solicitar por correo hosting gratuito de relé beta para pruebas
- Arrancar la Raspberry Pi y emparejarla desde la app móvil
- Si se necesita elegir hardware o un VPS, la Build Your Own Guide ofrece sugerencias de hardware y una ruta sencilla para empezar
App móvil
- Después de la configuración, la app móvil permite revisar de forma remota, consultar eventos recientes y abrir clips cifrados
- Enlaces de la app móvil
Seguridad y builds reproducibles
- El modelo de seguridad incluye diseño de relé no confiable, secreto hacia adelante y seguridad posterior a la intrusión
- La forma de reportar vulnerabilidades está en SECURITY.md
- El proyecto distribuye Secluso OS, una imagen precompilada para Raspberry Pi
- Secluso Deploy genera credenciales únicas en la máquina del usuario y las inyecta en la imagen precompilada
- Secluso OS, la herramienta de despliegue, los binarios de runtime y la app de Android son completamente reproducibles
- Los materiales de verificación están en
- releases/README.md: verificadores de reproducibilidad para binarios y herramienta de despliegue
- mobile_client/tool/repro/README.md: verificador de reproducibilidad de la app móvil de Android
- os/README.md: verificador de reproducibilidad de Secluso OS
- Las imágenes deben verificarse antes de que la herramienta de despliegue las modifique y deben descargarse directamente desde la release
Contribuciones y advertencias
- Se aceptan preguntas y contribuciones, y las contribuciones se realizan según la licencia del proyecto
- El contacto es secluso@proton.me
- Este proyecto usa cifrado, por lo que es necesario verificar las leyes locales antes de usarlo
- El usuario debe usarlo bajo su propia responsabilidad, y los autores del proyecto no ofrecen garantías sobre privacidad ni seguridad del hogar
1 comentarios
Comentarios de Hacker News
Proyecto realmente genial. Por las razones mencionadas arriba no había instalado cámaras de seguridad en casa, pero ver esto me hace reconsiderarlo.
Combinado con el firmware de código abierto https://github.com/openmiko/openmiko, podría ser una combinación potente para personas que priorizan la privacidad.
Así no haría falta una máquina separada que actúe como hub y la configuración sería mucho más sencilla.
Si necesitas un diseño de hardware + firmware de código abierto para una cámara con sensor de detección de movimiento, está aquí:
https://github.com/maxlab-io/tokay-lite-pcb
También se puede comprar:
https://www.mouser.ca/ProductDetail/Maxlab/TOKAY-LITE-01?qs=...
Todos los productos cerrados que he visto ajustan el iris/la exposición según la exposición promedio del cuadro, así que las placas salen como rectángulos completamente blancos.
Para la grabación nocturna habría que hacer que recorra exposiciones claras y oscuras.
Si se usa KEM[1] para crear una estructura tipo sealed_box[2], se puede proteger la privacidad incluso en situaciones en las que el hardware de la cámara sea incautado físicamente.
También se puede ofrecer resistencia cuántica usando juntos ML-KEM, es decir Kyber y McEliece-KEM, ECDH o RSA-KEM.
En sistemas así, el enfoque tradicional con claves simétricas también es resistente a la computación cuántica por sí mismo, pero el hardware de la cámara tiene una clave simétrica de largo plazo que podría extraerse después de una incautación.
Un mecanismo de ratchet que hashee las claves cada cierto tiempo puede ayudar, pero no tiene autorrecuperación y existe el riesgo de que se recuperen claves antiguas desde el almacenamiento permanente.
[1] <https://en.wikipedia.org/wiki/Key_encapsulation_mechanism>
[2] <https://libsodium.gitbook.io/doc/public-key_cryptography/sea...>
Hace algunos años quería crear un sistema de seguridad doméstica autosoberano para toda una comunidad y una HOA. Hablé con ingenieros de IBM sobre escanear video con modelos de machine learning cerca de los dispositivos.
Compré cámaras que usaban RTMP y RTSP y se las envié a desarrolladores; después, hacer streaming a algún lugar con WebRTC no fue difícil. WebRTC tiene cifrado de extremo a extremo.
Sin embargo, mi caso de uso era almacenar video cifrado, usando una clave distinta por minuto y por cámara, y había que definir con claridad el protocolo de descifrado.
Creo que el problema de seguridad no incluye solo un extremo, es decir, grabar delitos, sino también el otro extremo: la vigilancia masiva y “quién vigila a los vigilantes”.
Hay un texto más largo aquí: https://community.qbix.com/t/balancing-privacy-and-accountab...
Si quieres colaborar en una startup que venda esto a propietarios de viviendas y comunidades cerradas, puedes contactar a greg en el dominio qbix.com.
Si se habla de cifrado de extremo a extremo, uno entendería que el tráfico entre la cámara y la app está cifrado, pero en realidad no es así.
Para eso, la app dentro de la cámara tendría que soportar el sistema, y aunque es posible en muchas cámaras.
Más aún si se suma el contexto de usar servidores y servicios de notificaciones no confiables.
Pongo todos los dispositivos no confiables, incluidas las cámaras, en una VLAN sin acceso a internet; desde la VLAN principal se puede acceder a ellos, pero en sentido contrario está bloqueado.
En la VLAN principal ejecuto Frigate y Home Assistant para conectarme a las cámaras. Desde fuera de casa accedo con WireGuard.
Me pregunto cuál es el propósito de incluir un componente “servidor” no confiable. ¿La idea es ejecutarlo en algún lugar distinto del “hub de cámaras” confiable, por ejemplo en un servidor en la nube?
Esta parte es clave para la afirmación de que Privastead ofrece mejor privacidad que otras soluciones, pero no se explica.
Mi NVR [1] solo usa un servidor confiable ubicado en el mismo edificio que las cámaras. Yo también recomiendo impedir que las cámaras tengan acceso a internet, porque el software cerrado suele ser una pesadilla total en términos de privacidad y seguridad.
[1] https://github.com/scottlamb/moonfire-nvr
Personalmente uso una VM barata de DigitalOcean.
Me parece interesante la parte de “garantizar que solo el hub y la app móvil puedan acceder al video sin cifrar”.
Desde la implementación en Rust de OpenMLS, el almacenamiento seguro de extremo a extremo y los vectores TLS, si una configuración DIY de cámaras domésticas se conecta a internet mediante el hub de Privastead, ya no hace falta tunneling seguro.
También parece posible agregar aquí tecnología de reconocimiento facial y monitoreo en tiempo real.
Si alguna vez viste eigenfaces, te dará la impresión de que se parecen a humanos primitivos. Un método es el análisis de componentes principales (PCA), que separa las características principales de los rostros humanos del ruido relacionado con los rasgos más esenciales del rostro.
Dado que hay mucho foco en la seguridad, también podría ser interesante mencionar que existen cámaras compatibles con Secure Boot. Tengo entendido que Axis es uno de los fabricantes que se concentra en esta función.