Centro de Confiança
Nossas alegações de segurança são respaldadas por recursos verificáveis, e não apenas selos. Esta página reúne nossas políticas, o status atual do sistema, a arquitetura técnica e os provedores com quem trabalhamos, além de indicar claramente o que ainda não temos.
Recursos de verificação
Para verificar uma reclamação, não leia textos de marketing — vá para as fontes abaixo.
Divulgação de Vulnerabilidades
Escopo, princípios de proteção e o processo de relatório privado.
Status do Sistema em Tempo Real
Estado atual do serviço e histórico de tempo de atividade dos últimos 90 dias.
Arquitetura Técnica
Detalhes de criptografia, modelo de ameaças e limites conhecidos tanto da rota Bluetooth offline quanto da camada da internet.
Política de Privacidade
Quais dados residem onde, quando são compartilhados e como são excluídos.
security.txt
Conformidade com RFC 9116, registro de contato de segurança legível por máquina.
Código de Código Aberto
O cliente móvel está no GitHub sob a licença AGPL-3.0; as reivindicações podem ser auditadas a partir do próprio código.
Entre em contato com a Equipe de Segurança
Canal direto para relatar vulnerabilidades de segurança: security@crisisconnect.network
Nossas práticas de segurança
- A comunicação é criptografada de ponta a ponta em ambas as rotas suportadas: mensagens da internet viajam como envelopes criptografados que o servidor não pode ler, e mensagens Bluetooth vão diretamente do dispositivo para o dispositivo.
- Em comunicações normais entre pessoas próximas, o histórico de mensagens não é replicado em um servidor central; os dados permanecem principalmente no seu dispositivo.
- O código fonte do cliente móvel está disponível sob a licença AGPL-3.0; as alegações de criptografia podem ser verificadas independentemente.
- Um registro security.txt conforme RFC 9116 e uma política de divulgação de vulnerabilidades publicada fornecem aos pesquisadores um caminho definido para relatar.
- A saúde do sistema é publicada em uma página de status ao vivo alimentada por endpoints públicos.
- Não há anúncios, nenhum modelo de receita baseado em rastreamento e nenhuma venda de dados.
Criptografia e protocolos
Os protocolos em uso, não um rótulo. O modelo de ameaças completo, os limites conhecidos e as decisões de projeto estão documentados na página da arquitetura técnica.
Mensagens na internet (mensagens, notas de voz, anexos)
Protocolo Signal (libsignal): Dobro Ratchet com acordo de chaves pós-quântico PQXDH, proporcionando confidencialidade. Para compatibilidade com clientes mais antigos, uma envelope ECIES autenticada (ECDH P-256 + HKDF-SHA-256 + AES-256-GCM) é usada; esse caminho não fornece confidencialidade, e tentativas de degradação são rejeitadas após o estabelecimento de uma sessão Signal.
Chamadas e videoconferências (um para um)
WebRTC DTLS-SRTP. Para chamadas, o sinal nunca atravessa o servidor em texto simples — ele viaja dentro de envelopes de mensagens criptografados ponto a ponto — e o TURN não consegue descriptografar os dados de mídia. Chamadas em canais autorizados usam um caminho separado, onde o sinal passa pela infraestrutura de painel controlada por membros.
Mensagens próximas (Bluetooth)
AES-256-GCM (IV de 96 bits, tag de autenticação de 128 bits) para contatos emparelhados por QR. Fluxos autorizados de resposta usam chaves de sessão efêmeras ECDH P-256 + HKDF-SHA-256 e certificados de papel P-256 validados offline.
Identificação e verificação
A chave de identidade P-256 legada é armazenada no AndroidKeyStore com suporte de hardware em dispositivos suportados. A chave de identidade do Signal opera em software para operações de ratchet e é armazenada criptograficamente em repouso sob uma chave de Keystore — um trade-off deliberado de design para a confidencialidade. Os contatos podem ser verificados comparando números de segurança de 60 dígitos.
O que não é criptografado de ponta a ponta
O relatório SOS para painéis de resposta autorizados — intencionalmente legível para que as equipes possam agir com base nele — e metadados de entrega/sinalização (identificadores, marcas de tempo, IPs). Não escondemos isso; os detalhes estão na arquitetura técnica e na política de privacidade.
Revise o modelo de ameaças completo na arquitetura técnica →
Prestadores de serviços e hospedagem
Trabalhamos com os seguintes prestadores de serviços terceiros (subsessor) para fornecer o serviço. O conteúdo criptografado de ponta a ponta não pode ser lido por esses provedores; esta página é atualizada quando a lista muda.
| Provedor | Propósito | Localização |
|---|---|---|
| Google Firebase (Google LLC) | Autenticação, banco de dados, armazenamento, funções em nuvem, notificações, hospedagem de sites, análise e relatórios de falhas | EUA (us-central1) |
| Cloudflare, Inc. | RETRAN de mídia para chamadas na internet | Rede global Anycast (baseada nos EUA) |
| MapTiler AG | Entrega de tiles de mapa | Suíça (CDN global) |
| CARTO | Tiles de mapa base para os mapas no painel da web | CDN global |
| Google Play · Apple App Store | Distribuição e atualizações de aplicativos | Global |
O que ainda não temos
Não vamos reivindicar o que não temos. Até hoje:
- Nós ainda não publicamos um relatório independente de auditoria de segurança ou teste de penetração; é o principal investimento em confiança na nossa agenda.
- Não possuímos certificação ISO 27001 ou SOC 2.
- Não operamos um programa de recompensas por vulnerabilidades pagos; o processo de divulgação responsável está definido na página de segurança.
Esta página não faz novas reivindicações; ela apenas coleta recursos existentes e verificáveis em um único lugar.