Privastead - Sistema open source de câmeras de segurança residencial pessoais (com suporte a criptografia de ponta a ponta)
(github.com/privastead)- Secluso é um sistema DIY pessoal de câmeras de segurança residencial baseado em Raspberry Pi, que permite ver vídeo ao vivo, notificações e gravações pelo celular sem entregar as imagens a um provedor de nuvem
- O acesso remoto tem suporte a criptografia de ponta a ponta; no fluxo padrão, o Secluso Deploy cuida da criação da imagem, do pareamento e da configuração do relay, com meta de configuração em 5 minutos
- O hardware compatível inclui Raspberry Pi Zero 2W, Raspberry Pi Camera Module V1/V2 ou câmeras baseadas nos sensores Sony OV5647·IMX219, Android ou iPhone, uma conta em relay em Linux VPS ou hospedagem gratuita de relay beta para testes
- O método de implantação injeta credenciais únicas geradas na máquina do usuário em uma imagem pré-compilada do Secluso OS, e oferece builds reproduzíveis dos binários de runtime, da ferramenta de implantação, do app Android e do Secluso OS
- O modelo de segurança inclui design com relay não confiável, forward secrecy e segurança pós-comprometimento, mas é necessário verificar as leis locais sobre o uso de criptografia e a responsabilidade é do usuário
O que o Secluso oferece
- Secluso é um sistema pessoal de câmeras de segurança residencial para Raspberry Pi
- O usuário pode usar os seguintes recursos no celular
- Ver vídeo ao vivo
- Receber notificações
- Abrir gravações
- O objetivo é acessar remotamente as imagens de segurança residencial sem confiá-las a um provedor de nuvem
- O projeto é desenvolvido pela Secluso, Inc., e Ardalan Amiri Sani e John Kaczman são indicados como cofundadores
Principais recursos
-
Acesso remoto com criptografia de ponta a ponta
- Suporta acesso a vídeo ao vivo, notificações e gravações pelo celular
-
Configuração em 5 minutos
- No fluxo de configuração comum, o Secluso Deploy cuida da criação da imagem, do pareamento e da configuração do relay
-
Open source
- Você pode inspecionar o código, fazer self-hosting e contribuir
-
Releases totalmente reproduzíveis
- É possível verificar, com base no código-fonte público, os binários de runtime, a ferramenta de implantação, o app móvel para Android e o Secluso OS
Requisitos
-
Raspberry Pi
- Raspberry Pi Zero 2W
-
Câmera
- Raspberry Pi Camera Module V1 ou V2
- Ou câmera baseada nos sensores Sony OV5647·IMX219
-
Relay
- Login em um Linux VPS do usuário
- Ou e-mail solicitando hospedagem gratuita de relay beta durante os testes
-
Celular
- Android ou iPhone para pareamento, notificações e reprodução
Fluxo de configuração rápida
- Baixe o Secluso Deploy na release mais recente
- Gere localmente uma imagem personalizada do Secluso OS e um código QR secreto da câmera
- Faça o Secluso Deploy provisionar seu relay via SSH, ou solicite por e-mail a hospedagem gratuita de relay beta para testes
- Inicialize o Raspberry Pi e faça o pareamento no app móvel
- Se precisar escolher hardware ou VPS, o Build Your Own Guide oferece sugestões de hardware e um caminho simples para começar
App móvel
- Após a configuração, o app móvel permite verificação remota, revisão de eventos recentes e abertura de clipes criptografados
- Links do app móvel
Segurança e builds reproduzíveis
- O modelo de segurança inclui design com relay não confiável, forward secrecy e segurança pós-comprometimento
- O método para reportar vulnerabilidades está em SECURITY.md
- O projeto distribui o Secluso OS, uma imagem pré-compilada para Raspberry Pi
- O Secluso Deploy gera credenciais únicas na máquina do usuário e as injeta na imagem pré-compilada
- O Secluso OS, a ferramenta de implantação, os binários de runtime e o app Android são totalmente reproduzíveis
- Os materiais de verificação estão em
- releases/README.md: verificadores de reprodutibilidade para binários e ferramenta de implantação
- mobile_client/tool/repro/README.md: verificador de reprodutibilidade do app móvel Android
- os/README.md: verificador de reprodutibilidade do Secluso OS
- A imagem deve ser verificada antes de ser modificada pela ferramenta de implantação, e deve ser baixada diretamente da release
Contribuições e observações
- Perguntas e contribuições são bem-vindas, e as contribuições são feitas de acordo com a licença do projeto
- O contato é secluso@proton.me
- Este projeto usa criptografia, portanto é necessário verificar as leis locais antes de usá-lo
- O usuário deve usar por sua própria conta e risco, e os autores do projeto não oferecem garantias quanto à privacidade ou à segurança residencial
1 comentários
Comentários no Hacker News
Projeto realmente muito legal. Pelos motivos mencionados acima, eu não tinha instalado câmeras de segurança em casa, mas isso me fez repensar
Combinado com o firmware open source https://github.com/openmiko/openmiko, parece que seria uma combinação poderosa para pessoas que valorizam privacidade
Assim não seria necessária uma máquina separada para atuar como hub, tornando a configuração muito mais fácil
Se você precisa de um projeto de hardware + firmware open source para câmeras com sensor de detecção de movimento, aqui está:
https://github.com/maxlab-io/tokay-lite-pcb
Também dá para comprar:
https://www.mouser.ca/ProductDetail/Maxlab/TOKAY-LITE-01?qs=...
Todos os produtos fechados que vi ajustam a abertura/exposição com base na exposição média do quadro, então a placa sai como um retângulo totalmente branco
Para gravação noturna, seria preciso fazê-lo varrer exposições claras e escuras
Usando KEM[1] para criar uma estrutura do tipo sealed_box[2], é possível preservar a privacidade mesmo em uma situação em que o hardware da câmera seja fisicamente apreendido
Também é possível oferecer resistência quântica usando ML-KEM, ou seja, Kyber, junto com McEliece-KEM, ECDH ou RSA-KEM
Em sistemas assim, a abordagem tradicional com chave simétrica por si só também é resistente a ataques quânticos, mas o hardware da câmera mantém uma chave simétrica de longo prazo que pode ser extraída após a apreensão
Um mecanismo de ratchet que faz hash da chave em intervalos regulares pode ajudar, mas não tem autorrecuperação e há o risco de chaves antigas serem recuperadas do armazenamento permanente
[1] <https://en.wikipedia.org/wiki/Key_encapsulation_mechanism>
[2] <https://libsodium.gitbook.io/doc/public-key_cryptography/sea...>
Alguns anos atrás, eu queria criar um sistema de segurança residencial autossoberano para comunidades inteiras e HOAs. Conversei com engenheiros da IBM sobre escanear vídeo com modelos de machine learning perto dos dispositivos
Comprei câmeras que usam RTMP e RTSP e as enviei para desenvolvedores; depois disso, não foi difícil fazer streaming para algum lugar via WebRTC. O WebRTC tem criptografia de ponta a ponta
Porém, no meu caso de uso, eu precisava armazenar vídeo criptografado, usar uma chave diferente por minuto e por câmera, e definir claramente o protocolo de descriptografia
Vejo que a questão de segurança não inclui apenas uma ponta, isto é, gravar crimes, mas também a outra ponta, ou seja, vigilância em massa e “quem vigia os vigilantes”
Há um texto mais longo aqui: https://community.qbix.com/t/balancing-privacy-and-accountab...
Se quiser cofundar uma startup para vender isso a proprietários de imóveis e condomínios fechados, entre em contato com greg no domínio qbix.com
Se é criptografia de ponta a ponta, eu entenderia que isso significa que o tráfego entre a câmera e o app é criptografado, mas na prática não é isso
Para isso, o app dentro da câmera teria de dar suporte ao sistema, e isso é possível em muitas câmeras
Especialmente quando se acrescenta o contexto de usar servidores e serviços de notificação não confiáveis
Coloco todos os dispositivos não confiáveis, incluindo câmeras, em uma VLAN sem acesso à internet; a VLAN principal consegue acessá-los, mas o caminho inverso fica bloqueado
Na VLAN principal rodo Frigate e Home Assistant para me conectar às câmeras. De fora de casa, acesso via WireGuard
Fico curioso sobre o objetivo de incluir um componente de “servidor” não confiável. A ideia é executá-lo em algum lugar diferente do “hub de câmeras” confiável, por exemplo em um servidor na nuvem?
Esse ponto é central para a afirmação de que o Privastead oferece mais privacidade do que outras soluções, mas não há explicação
Meu NVR [1] usa apenas um servidor confiável no mesmo prédio que as câmeras. Eu também recomendo impedir que as câmeras acessem a internet, porque softwares fechados geralmente são um pesadelo completo em termos de privacidade e segurança
[1] https://github.com/scottlamb/moonfire-nvr
Pessoalmente, uso uma VM barata da DigitalOcean
Achei interessante a parte que diz “garante que apenas o hub e o app móvel possam acessar vídeo não criptografado”
Do ponto de vista da implementação em Rust do OpenMLS, armazenamento seguro de ponta a ponta e vetores TLS, quando uma configuração DIY de câmeras domésticas se conecta à internet por meio do hub Privastead, o tunelamento seguro deixa de ser necessário
Também parece possível adicionar reconhecimento facial e monitoramento em tempo real a isso
Se você já viu eigenfaces, terá a impressão de que parecem humanos primitivos. Um método é a análise de componentes principais (PCA), que separa as principais características de um rosto humano do ruído relacionado aos traços mais essenciais do rosto
Como há bastante foco em segurança, também pode ser interessante notar que existem câmeras com suporte a Secure Boot. Pelo que sei, a Axis é uma das fabricantes que se concentram nesse recurso