Arquitetura Técnica para Dispositivos Móveis

Conteúdo

Esta página explica como o aplicativo móvel Crisis Connect estabelece a confiança, transmite mensagens e chamadas criptografadas de ponta a ponta enquanto a internet estiver ativa, continua funcionando através do Bluetooth direto quando as redes caem e direciona os socorristas para caminhos seguros.

Código Abertoemirhan-duman/Crisis-Connect

BLE + RFCOMM

Caminho Padrão de Incidente

Wi-Fi Aware + GATT

Camadas de Extensão Controladas

AES-GCM + ECDH

Perfil de Confiança Seguro

Android 1.0.4 · iOS 1.1.0

Versões para a Loja Pública

Crisis Connect é um sistema de comunicação de emergência baseado em offline. Enquanto a internet estiver disponível, oferece mensagens criptografadas de ponta a ponta, além de chamadas de voz e vídeo; quando a internet e a infraestrutura celular falharem ou sobrecarregarem, o mesmo aplicativo continua funcionando através das rádios de curto alcance dos telefones próximos. A arquitetura Android mantém o caminho da incidente na conexão Bluetooth local, constrói a camada online em envelopes criptografados de ponta a ponta, adiciona camadas de expansão apenas quando permitido pela política e trata a nuvem como um plano de entrega e confiança que nunca vê conteúdo em texto simples.

Resumo do Sistema

Caminho de mensagem baseado em offline: Dispositivos próximos descobrem uns aos outros via Bluetooth, então trocam payloads seguros através de um transporte ponto a ponto local sem depender da internet

Camada online: Enquanto a internet estiver ativa, as mensagens viajam como envelopes criptografados de ponta a ponta, as chamadas individuais funcionam usando WebRTC e os relatórios de SOS chegam aos painéis de resposta autorizados

Confiança explícita: Contatos conhecidos são provisionados fora da linha com QR, enquanto o Modo de Resgate promove apenas respondentes verificados em chats seguros de duas vias

Modelo de expansão controlada: Uma rede de respondentes autorizados e uma ampla coordenação pública existem, mas são separadas, restritas e intencionalmente não tratadas como a rota padrão

A nuvem não tem acesso ao conteúdo: Os serviços de backend lidam com a emissão de certificados, distribuição de pontos de confiança, sincronização de telemetria e entrega de mensagens criptografadas; em nenhum momento eles podem ler o conteúdo criptografado de ponta a ponta

Modelo de Operação

Suposições, escopo e limite atual de capacidade

O Crisis Connect foi projetado para ser útil tanto em estados: mensagens e chamadas criptografadas de ponta a ponta enquanto a internet estiver ativa, quanto na coordenação local que continua funcionando quando as redes de área ampla falharem. O peso das decisões arquitetônicas recai sobre o segundo momento: telefones próximos ainda funcionam, e os operadores precisam de uma camada de coordenação local controlada — não ilimitada.

Suposição de primeira prioridade: O aplicativo é projetado para incidentes em que a internet e o serviço celular estão indisponíveis ou sobrecarregados, mas os smartphones próximos ainda têm bateria e rádios utilizáveis.

Cliente pré-instalado: A participação civil assume que uma versão compatível do aplicativo já está instalada antes da perda de conectividade, ou ainda pode ser distribuída por meio de um fluxo local aprovado, enquanto a instalação permanece possível.

Comunicação via rádio local: A comunicação é baseada na proximidade. O Bluetooth é o caminho padrão, enquanto o Wi-Fi Aware é reservado para sessões de rede autorizadas entre respondentes em dispositivos suportados.

Conjunto de capacidades atuais: Atualizações de texto e localização seguras, voz ponto a ponto opcional, Modo de Resgate, bate-papo em rede para respondentes autorizados, mensagens na internet criptografadas de ponta a ponta, chamadas de voz e vídeo WebRTC e sincronização opcional de telemetria do Crisis Link estão dentro do escopo atual.

Postura de contenção de boatos: Mensagens para civis são direcionadas para contatos conhecidos, o SOS está aberto para descoberta, mas verificado para bate-papo seguro, e a coordenação pública em larga escala permanece opcional e limitada.

Princípios de Design

Local Antes da Nuvem

O sistema é projetado para funcionar totalmente sem a internet. A camada online complementa o caminho de emergência offline, em vez de substituí-lo; os pacotes de emergência locais permanecem nos caminhos de rádio do dispositivo para dispositivo.

Antes da Rede

O comportamento padrão é Bluetooth ponto a ponto. Modos de maior alcance são aplicados apenas sob controle explícito de função, capacidade e operador.

Tempo Executivo Limitado

O design assume condições de energia limitadas e instáveis no campo, portanto, os limites da fila, os limites de repetição, os serviços em primeiro plano e o escopo de chamadas únicas são intencionais.

A Confiança é Explícita

Os contatos ficam operacionais somente após a inicialização do QR mais verificação criptográfica de liveness, e os fluxos seguros para o respondente exigem verificação baseada em certificado.

Estação de Rádio Primária

Descoberta e controle BLE acima do transporte de dados via RFCOMM

O caminho padrão de incidente combina duas camadas Bluetooth com diferentes funções. O BLE lida com a descoberta leve, sinalização de serviço e trocas de controle de resgate, enquanto o Bluetooth Classic RFCOMM transporta o tráfego de dados mais pesado para texto, localização, mídia e voz opcional.

Camada de Descoberta e Controle

BLE (GAP/GATT)

Sinalização de presença, trocas de controle curtas, Anúncio do Modo de Resgate e descoberta de baixo consumo

Descoberta de pares de baixo consumo e transmissão de presença local para dispositivos próximos

Autenticação e trocas de controle que preparam sessões seguras antes da transferência de dados pesados

Comportamento do sinal de SOS e sinalização de nível de serviço para fluxos de trabalho no modo de Resgate

Camada de Transporte de Dados

Bluetooth Classic RFCOMM/SPP

Transporte confiável ponto a ponto para texto, localização, mídia e voz opcional

Sessões diretas de maior capacidade entre pares próximos após o sucesso da descoberta

Transferência segura de mensagens, imagens, arquivos e voz através de um protocolo definido pela aplicação

A compatibilidade pode incluir falhas seguras ou inseguras de sockets, portanto, a segurança da mensagem é garantida acima do socket

Alcance operacional: A faixa indicativa é de aproximadamente 50-150 m em linha de visão aberta, 30-80 m em áreas urbanas ou com obstáculos mistos, 10-30 m em ambientes internos e 5-20 m em obstruções semelhantes a escombros. Devido ao fato de que o alcance e o comportamento do socket variam entre os dispositivos, a confidencialidade é garantida no nível da aplicação, em vez de assumir que ela está presente apenas devido ao modo RFCOMM.

Extensões Controladas

Como a base se expande além do Bluetooth direto

O sistema expande intencionalmente o escopo em camadas cuidadosamente separadas. A rede de resposta segura e a coordenação pública ampla são ambas características reais na base, mas existem sob regras de confiança, ativação e governança diferentes.

Rede de Responders Autorizados

A linha de lançamento do Android inclui uma extensão opcional de chat em grupo seguro sobre Wi-Fi Aware para funções administrativas e de equipe autorizadas. Ela permanece desativada, a menos que ambas as verificações de certificado de função e capacidade da plataforma passem.

Canal Público GATT Opcional

Uma rede pública GATT separada pode ser habilitada a partir das Configurações Avançadas para bate-papo e anúncios gerais na área. Ela é intencionalmente de alcance amplo e deve ser tratada como tráfego de coordenação não confidencial.

Portas de Ativação Explícitas

A rede de resposta requer uma postura de papel local válida e hardware compatível. A rede pública permanece desativada, a menos que o usuário habilite explicitamente o modo de rede pública.

Controles de Abuso Limitados

O perfil público declarado congela o limite máximo de saltos em 4, aplica uma janela de tempo, orçamento de inundação por fonte, limites de tamanho de mensagem, supressão de duplicatas e uma fila de retransmissão limitada.

Confiança Bootstrap

Criação de confiança antes ou durante uma queda

Contatos podem criar confiança localmente por QR durante uma queda. Preparar reduz a pressão, mas não é pré-requisito do protocolo. Números verificados acrescentam o diretório online e o pareamento local Próximos após verificação prévia.

QR sem internet: dois celulares próximos trocam sessão e material criptográfico por QR e verificam e salvam o contato por Bluetooth; não há conta, SMS, SIM ou consulta ao servidor.

Contatos online: ambos verificam seus números com internet e o diretório adiciona o usuário encontrável sem QR.

Próximos offline: após verificação prévia, a troca local usa privadamente o número selecionado, não o transmite e não requer internet ativa.

Ativação: a identidade só é salva depois das verificações criptográficas e do link local aplicáveis.

QR é o caminho local universal e funciona durante a queda. Os caminhos por telefone exigem verificação prévia de ambos; o diretório precisa de internet atual e Próximos não.

Modelo de Identidade e Confiança

Confiança QR local, descoberta telefônica verificada e certificados de resposta

O Crisis Connect utiliza diferentes caminhos de confiança para diferentes relacionamentos. Contatos conhecidos e socorristas verificados não compartilham o mesmo modelo de inicialização, autorização ou recuperação.

Caminho Seguro para Contatos Conhecidos

Contatos podem criar confiança por QR sem conta, verificação de telefone ou internet. O diretório online exige números verificados; Próximos reutiliza números já verificados para pareamento Bluetooth local offline.

Autenticação do Residente

Interações de resgate validam certificados de papel ECDSA offline contra uma chave pública autoritária, verificando assinatura, UID do proprietário, escopo da função e janela de validade antes da promoção segura.

Requisitos de rede

Sessões Wi-Fi Aware de rede autorizadas exigem tanto um certificado de papel válido local quanto suporte da plataforma. Tentativas de conexão não autorizadas são rejeitadas antes da ativação do chat de rede.

Ciclo de Vida de Chaves e Certificados

Os certificados de papel são de curta duração na configuração padrão (perfil do emissor atual: TTL de 72 horas). As chaves de identidade locais residem no AndroidKeyStore, outros materiais sensíveis são protegidos em armazenamento criptografado, e a ausência ou expiração da postura do respondente força a renovação ou reprovisão.

Ciclo de Vida da Mensagem

Do descobrimento à progressão de confirmação

Esta seção aborda o ciclo de vida das rotas seguras (Bluetooth) de proximidade; a comunicação na internet é abordada na seção Camada Online. Nas rotas de proximidade, os dados são criptografados no dispositivo do remetente e descriptografados no dispositivo do destinatário. Se um peer estiver offline ou temporariamente fora do alcance, a entrega aguarda uma conexão local em vez de escapar para o relay na nuvem.

01A descoberta e o controle BLE indicam a disponibilidade do dispositivo e preparam a sessão local.

02A configuração do link RFCOMM abre o transporte de alta velocidade usado para texto, localização, mídia e voz opcional.

03A ativação com contato conhecido usa os quadros de desafio-resposta `HSK_REQ` e `HSK_ACK`; a sessão só fica ativa após a validação com tempo limite ter sucesso.

04`SEC_MSG` frames transport payloads criptografados pelo remetente, identificados por UUID, IV e texto cifrado; o receptor verifica a autenticação antes da persistência local.

05A progressão de `ACK` avança as mensagens na fila através das semânticas de entregue e lido, sem duplicar registros persistidos com UUID.

06As transferências de voz, imagem e arquivo são redefinidas para famílias de registros JSON tipados, com chunking, janelas de repetição e verificações de integridade no final da transferência.

07As regras de repetição, duplicação e idempotência dependem da unicidade do UUID, caches limitados e comportamento de rejeição no lado do receptor, em vez de assumir uma conexão perfeita.

08O canal GATT público é logicamente separado dessas rotas seguras designadas e não deve ser tratado como transporte confidencial.

Estado do protocolo: Na versão básica do Android, o tráfego RFCOMM é delimitado por nova linha em UTF-8, com linhas de controle separadas por pipe e famílias JSON tipadas para fluxos de mídia ou controle de chamadas mais ricos.

Caminho de Voz

Opus sobre Bluetooth ponto a ponto

A voz é opcional e intencionalmente conservadora. Ela funciona como streaming em tempo real peer-to-peer sobre o transporte ponto a ponto, é criptografada antes da transmissão e deve ser avaliada com base tanto na bateria quanto na estabilidade do RF.

Perfil de Voz

CodecOpus

Taxa de Amostragem16 kHz

Armação / Pacote10 ms x 5 = ~50 ms

Metas de Taxa de Bits20 kbps WB / 16 kbps NB

Buffer de Jitter20-50 ms (30 ms padrão)

Alvo de Bufferização~70-100 ms

Sequência de Chamada

01O áudio é capturado, codificado com Opus, criptografado e enviado através do link RFCOMM ativo, em vez de por meio de uma pilha de mídia separada da internet.

02O escopo básico assume uma única sessão de voz ativa por link ponto a ponto; múltiplas chamadas de voz concorrentes em um único dispositivo estão fora do escopo.

03Um ciclo de controle de um segundo pode alternar entre perfis de banda larga e estreita, com um tempo de resfriamento de seis segundos e confirmações de configuração negociadas antes que as alterações de perfil tenham efeito.

04A evidência do piloto deve relatar o tempo de estabelecimento da chamada, perda, distribuição de latência e impacto incremental na bateria sob condições específicas do cenário, em vez de apenas continuidade anedótica.

Política Adaptativa

A implementação retrocede de WB para NB quando os tempos de escrita aumentam, ocorrem novamente, ou a profundidade de jitter se torna instável; ela só volta a ser atualizada após uma recuperação sustentada. Esta é uma política de continuidade limitada, não uma garantia universal de QoS.

Camada Online

Mensagens e chamadas criptografadas de ponta a ponta enquanto a internet estiver ativa

Com uma conexão à internet, o Crisis Connect funciona como um mensageiro que você pode usar diariamente: chat, chamadas de voz e vídeo criptografados de ponta a ponta, e relatórios de SOS que chegam aos painéis de resposta autorizados. Esta camada não substitui a arquitetura offline; ela fica em cima dela, seguindo o mesmo princípio: o conteúdo é criptografado no dispositivo, e os servidores apenas lidam com envelopes criptografados, além das informações necessárias para a entrega.

Mensagens Criptografadas de Ponta a Ponta

Mensagens, notas de voz e anexos deixam o dispositivo apenas como envelopes criptografados de ponta a ponta; os servidores não podem abri-los. Quando ambas as partes suportam, a sessão funciona no protocolo Signal via libsignal (Double Ratchet mais acordo de chaves PQXDH pós-quântico) com confidencialidade reversa. Um envelope ECIES autenticado (ECDH P-256 + HKDF-SHA-256 + AES-256-GCM) cobre clientes mais antigos; ele não fornece confidencialidade reversa, e uma vez que uma sessão Signal existe, tentativas de degradação para esse formato são rejeitadas. A chave de identidade P-256 legária reside no AndroidKeyStore com suporte a hardware em dispositivos suportados; a chave de identidade do Signal é armazenada criptografada em repouso sob uma chave Keystore. Os contatos podem ser verificados com um número de segurança de 60 dígitos.

Chamadas de Voz e Vídeo WebRTC

Chamadas individuais funcionam com WebRTC: áudio Opus, vídeo de câmera até 720p e compartilhamento de tela. Os dados são criptografados com DTLS-SRTP, e os sinais SDP e ICE nunca atravessam o servidor em texto plano — eles viajam dentro de envelopes de mensagens criptografadas de ponta a ponta. Quando uma conexão direta não é possível, os dados de mídia são roteados através do Cloudflare TURN relay; as credenciais TURN são geradas no lado do servidor com tempos de vida curtos, e se o serviço estiver inacessível, a chamada retorna à conectividade direta sobre STUN.

SOS na Internet

Com internet disponível, o SOS prossegue por duas rotas separadas. O relatório enviado para painéis de resposta autorizados inclui localização, precisão, nível da bateria e país, e é deliberadamente criptografado de ponta a ponta para que os painéis possam lê-lo. Os alertas SOS e as atualizações de localização em tempo real enviadas para seus contatos de emergência viajam como envelopes criptografados de ponta a ponta, como qualquer outra mensagem. Sem conectividade, o relatório é enfileirado e enviado quando a internet retornar; o beacon BLE SOS continua funcionando como o principal caminho offline em todos os casos.

A seleção de transporte é automática: se houver uma conexão Bluetooth com o dispositivo parceiro, a mensagem usa o caminho local; caso contrário, a internet é usada; se nenhum estiver disponível, ela aguarda na fila de encaminhamento e a mesma conversa continua como uma única comunicação. O limite honesto: o conteúdo permanece criptografado de ponta a ponta, mas os metadados de entrega e sinalização (identificadores do remetente e destinatário, marcas de tempo, endereços IP) são processados por servidores; cópias dos envelopes confirmados são removidas dos servidores, e os não entregues são eliminados após um período limitado.

Modo de Resgate

Transmissão de SOS, verificação do socorrista, promoção de bate-papo seguro

O Modo de Resgate separa intencionalmente a descoberta da confiança. Uma vítima pode ser encontrada sem prévia conexão, mas o bate-papo seguro de duas vias começa somente após a verificação do socorrista.

01 Sinalização de Emergência

Sinalização de Emergência

O SOS acionado pelo usuário coloca o dispositivo em um estado de emergência local e emite anúncios BLE conectáveis para o serviço de resgate `0xCC00`.
O conteúdo do anúncio permanece mínimo na configuração padrão: o sinal de rádio expõe a descoberta em nível de serviço, em vez de uma identidade totalmente autenticada.
A transmissão de SOS foi projetada para melhorar a descoberta de respondentes próximos durante as varreduras de setores quando as redes de área ampla estão indisponíveis.
O custo de privacidade é explícito: a capacidade de descoberta aumenta no modo SOS, portanto, consentimento, estado da interface clara e controles de taxa são importantes.

02 Verificação do Residente

Verificação do Residente

Após a conexão, o socorrista e a vítima trocam os desafios e respostas de autenticação em `0xCC10` e `0xCC11` e derivam uma chave de sessão ECDH efêmera.
A prova de papel criptografada chega em `0xCC20` e deve incluir referência de certificado, escopo do papel, tempo de emissão e data de expiração.
Verificações de validação são realizadas para assinatura, autoridade de confiança, vinculação da transcrição, expiração e autorização do papel antes que qualquer promoção segura seja permitida.
Provas expiradas, malformadas ou de escopo incorreto são rejeitadas na entrada, em vez de serem downgradadas para o chat de resgate.

03 Chat de Resgate Seguro

Chat de Resgate Seguro

Somente após a verificação bem-sucedida, a vítima emite `OK` no `0xCC21`, abrindo o caminho seguro.
Chat de resgate criptografado em ambas as direções prossegue nos endereços `0xCC30` e `0xCC31` com semântica de ACK `ENTREGUE` e `LIDO`.
As restrições atuais incluem tamanho de pacote de papelada limitado, fragmentação consciente do MTU e um envelope de pacote de chat seguro grande, mas finito.
Clientes não verificados nunca alcançam o canal de escrita seguro; a porta de promoção é uma barreira rígida, não uma interface UI.

A principal propriedade de segurança é que o Modo de Resgate não equipara a descoberta com confiança. A descoberta próxima é suficientemente aberta para encontrar vítimas; o chat de resgate seguro não é.

Serviços em segundo plano

Execuções e escopo da plataforma

O principal ambiente institucional validado é a arquitetura de serviço Android. Um cliente iOS público está disponível com mensagens centradas em BLE e lógica de resgate controlada por respondentes, mas a evidência de implantação de nível de respondente ainda deve ser revisada por plataforma.

SVC-01

Serviço RfcommEmFundo

Mantém o ouvinte de transporte clássico, a sinalização de chamadas e os ciclos de vida da transferência de mídia ou arquivos para sessões locais.

SVC-02

Serviço GattSOSServer

Hospeda o transmissor SOS do Modo de Resgate e o ponto de extremidade de interação seguro com os socorristas usado pelas vítimas nos fluxos de resgate BLE.

SVC-03

Serviço GattRescueClient + Serviço MeshAware

Gerencia as sessões de resgate BLE do lado do socorrista e, quando autorizado, a descoberta e autenticação da rede Wi-Fi Aware com comportamento de reconexão limitado.

SVC-04

CrisisLink, Ferramentas Offline e Aplicativo para iOS

O serviço CrisisLinkForegroundService limpa os dados de telemetria em fila após a recuperação da internet validada, o serviço OfflineDownloadService gerencia as regiões de mapa offline, e o aplicativo iOS permanece ativo, mas ainda está sujeito às suas próprias verificações de disponibilidade.

Criptografia e Modelo de Ameaças

Garantias em nível de aplicação acima de condições de rádio instáveis

O comportamento dos sockets Bluetooth e as condições de RF variam entre os dispositivos, portanto, as garantias de caminho seguro são definidas no nível da aplicação. O perfil criptográfico, as suposições sobre ameaças e o modelo de custódia de chaves são partes explícitas da arquitetura.

Camada 01

Caminho de contato seguro: Contatos provisionados por QR usam AES-256-GCM com IVs de 96 bits e tags de 128 bits; quadros de handshake endurecidos não carregam material de chave em banda.

Camada 02

Certificados dos socorristas: O Modo de Resgate valida certificados de papel P-256 ECDSA offline contra uma chave pública de autoridade fixada antes da promoção do chat seguro.

Camada 03

Chaves da rede de socorristas: A rede Wi-Fi Aware autorizada usa uma chave de grupo compartilhada; o handshake seguro (GATT) de resgate deriva chaves de sessão por peer via ECDH P-256 efêmero, além de HKDF-SHA-256 e criptografa a conversa usando AES-256-GCM com AAD vinculado à mensagem.

Camada 04

Nonce e política de repetição: IVs gerados por CSPRNG, pacotes limitados por chave, reinício ou redefinição do handshake, caches de repetição e idempotência UUID são necessários para manter a operação segura do AES-GCM.

Camada 05

Custódia da chave: As chaves de assinatura de identidade do dispositivo residem no AndroidKeyStore (`dcs_attested_signing_key`), enquanto o material simétrico sensível é armazenado em preferências criptografadas e o backup permanece desabilitado.

Camada 06

Limite do canal público: Pacotes GATT públicos podem conter um envelope AES-GCM para integridade e formatação, mas o canal ainda é tratado como tráfego de coordenação pública não confidencial.

Camada 07

Envelope de mensagem da Internet: A rota preferida para mensagens na Internet é o protocolo Signal via libsignal (Double Ratchet + PQXDH pós-quântico); o envelope de compatibilidade usa ECDH P-256 + HKDF-SHA-256 + AES-256-GCM com AAD vinculado ao remetente, destinatário e conversa, e as atualizações para o formato legado são rejeitadas uma vez que uma sessão Signal existe.

Camada 08

Mídia e TURN de chamada: Chamadas WebRTC usam mídia criptografada com DTLS-SRTP, com sinalização da chamada dentro de envelopes criptografados de ponta a ponta; o TURN apenas encaminha pacotes criptografados, e as credenciais são geradas no servidor com tempos de vida curtos.

Camada 09

Modelo de ameaças: O design assume vigilância passiva por RF mais ataques ativos de retransmissão, falsificação, interferência, inundação de dispositivos e interrupção do plano de controle na nuvem. No caminho da Internet, os servidores e a infraestrutura de retransmissão são tratados como não confiáveis para conteúdo: o texto simples nunca chega a um servidor, enquanto os metadados de entrega permanecem visíveis.

Camada 010

Exclusões explícitas: Compromisso total do sistema operacional, coerção do usuário e interferência de rádio em escala nacional permanecem fora do escopo, portanto, as alegações de implantação não devem implicar proteção nessas áreas.

A defesa em profundidade aqui significa criptografia do dispositivo do remetente, verificação no lado do receptor, controle de acesso explícito e política de metadados limitada. Isso não elimina o impacto na privacidade de estar detectável por rádio.

Privacidade e Governança

Metadados, controle de informações e propriedade operacional

A segurança operacional em desastres depende tanto do fluxo de informações controlado quanto da criptografia. Decisões políticas, disciplina de metadados e rastreabilidade de evidências são parte da arquitetura técnica aqui.

Higiene de Informações

A comunicação civil padrão permanece dentro dos contatos pré-definidos, a descoberta de SOS é separada do chat seguro e o Public GATT deve reservar instruções oficiais para formatos de anúncio validados pelos respondentes.

Política de Metadados em Tempo Real

As transmissões de integração têm um tempo limitado, a prontidão regular evita identificadores estáveis e legíveis, o modo SOS expõe intencionalmente o UUID do serviço de Resgate, e a rede pública revela inerentemente os rótulos do remetente e os metadados de salto.

Armazenamento e Anonimização

A persistência de mensagens usa registros baseados em UUID, o histórico de chamadas é limitado a janelas delimitadas, chaves sensíveis permanecem no armazenamento local criptografado, e os logs do piloto devem pseudonimizar IDs de dispositivos e quantificar a localização.

Controle de Propriedade

As autoridades operacionais precisam de proprietários explícitos para emissão de certificados, cadência de bloqueio, troca de chaves, revogação de emergência e os artefatos de evidência usados na revisão Go ou No-Go.

A postura de anúncio confiável no Public GATT é um contrato de governança mais do que uma garantia de produto fechado hoje; a evidência de downgrade e a cobertura do analisador ainda são itens de revisão abertos.

Plano de Confiança Assistido por Nuvem

Fora da rota de emergência; apenas envelopes criptografados na rota online

O Crisis Connect pode funcionar totalmente offline para comunicação de contato a contato. Os serviços em nuvem realizam duas tarefas: estabelecimento de confiança com suporte de telemetria operacional, e entrega de envelopes criptografados para mensagens na internet. Em nenhum momento os servidores podem acessar conteúdo criptografado de ponta a ponta, e a rota de emergência mantém o funcionamento sem a nuvem.

Identificação e emissão

As autoridades podem emitir certificados de papel de resposta, rotacionar chaves e integrar o fluxo de confiança com o IAM institucional ou um IdP auto-hospedado como Keycloak.

Suporte à verificação offline

Os dispositivos armazenam os pontos de ancoragem de confiança e pacotes de políticas localmente, para que a verificação da resposta possa continuar sem conectividade na nuvem; snapshots de listas de bloqueio são uma extensão de implantação para janelas de conectividade.

Telemetry do Crisis Link

Responders autorizados podem enfileirar e sincronizar posteriormente snapshots de telemetria de resgate quando a internet retornar, mas este canal não transporta payloads de chat de emergência.

Entrega de mensagens criptografadas

Para mensagens na internet, o backend armazena apenas envelopes criptografados e metadados de roteamento para que as mensagens cheguem a destinatários offline; cópias do servidor são removidas após a confirmação da entrega, e os envelopes não entregues são eliminados após um TTL limitado.

Divisão do plano de confiança: Conteúdo de emergência por proximidade permanece em BLE, RFCOMM, Wi-Fi Aware ou o canal GATT público opt-in;

enquanto os sistemas na nuvem lidam com o ciclo de vida dos certificados, distribuição de pontos de confiança, sincronização de telemetria e entrega de envelopes criptografados para mensagens na internet.

Os deployments de produção devem continuar a armazenar as chaves de assinatura fora do código fonte e sob controles como HSM, KMS ou Secret Manager.

Portas de Evidência e Aceitação do Piloto

O que deve ser medido antes da implantação em larga escala

As reivindicações de arquitetura aqui devem ser avaliadas com base na evidência de campo, em vez apenas da intenção do protocolo. A aprovação do piloto deve ser baseada em dados de cenário, e não na intenção de design.

Sucesso na entrega de mensagens: Pelo menos 95% em até 30 segundos em cenários internos ou urbanos e 85% em condições semelhantes a escombros.

Latência de texto: A latência de ponta a ponta da mensagem deve permanecer em ou abaixo de 5 segundos nas condições operacionais planejadas.

Envelope de voz: A latência média de ida e volta deve estar em ou abaixo de 150 ms com perda de pacotes sustentada em ou abaixo de 3% durante chamadas ativas.

Impacto de energia: A descoberta em espera e a transmissão ou drenagem ativa devem permanecer dentro dos limites definidos pela missão; as evidências atuais do Pixel 7a em espera são complementares, não determinam o encerramento.

Fluxo de trabalho do socorrista: SOS, prova de função, troca segura de mensagens e ativação autorizada da rede devem passar em 100% dos cenários de validação roteirizados.

Contenção do abuso no canal público: Pacotes públicos malformados ou fora da janela devem ser descartados antes da retransmissão com >=99%, e anúncios não verificados de socorristas nunca devem ser exibidos como alertas confiáveis.

Sequência Recomendada para Pilotos

Piloto de Resposta: Inicie com uma frota de dispositivos treinados e valide a emissão de credenciais, o Modo de Resgate, o comportamento do serviço em segundo plano e a ativação da rede baseada em funções.

Matriz de Cenários: Realize simulações em ambientes internos, urbanos, abertos e com detritos, com intervalos fixos, bins RSSI, anotações de controle de tempo e rastreamento explícito de continuidade ou perda de voz.

Revisão de governança: Congelar parâmetros do canal público, documentar revogação e procedimentos de rolagem, mapear reivindicações para artefatos de evidência, e somente então considerar implantação gradual mais ampla.

Situação atual de evidências

O Bluetooth permanece baseado na proximidade; a cobertura é limitada pelo ambiente, obstrução, hardware e política de energia do SO.

O sistema suporta a coordenação setorial local, sem garantia de alcance para todos os vítimas em todas as condições sob os escombros.

Os fluxos civis padrão dependem de links locais diretos; os modos mesh exigem hardware compatível, ativação explícita e proximidade com rádio local.

A rede GATT pública é opcional, desativada por padrão e não recomendada como configuração sempre ativada para todos os perfis de usuário.

Conteúdo operacional sensível deve permanecer em caminhos ou canais de resposta seguros e controlados por funções, em vez de em superfícies de coordenação públicas.

Comportamento de retransmissão ou armazenamento e encaminhamento não gerenciado permanece fora do escopo da configuração base validada.

A evidência atual de implantação institucional validada se concentra na linha de lançamento Android; o iOS está disponível publicamente, mas ainda precisa de sua própria evidência de prontidão para resposta.

A variação no gerenciamento de bateria do dispositivo, sistema operacional e fabricante pode alterar significativamente o comportamento, portanto, os pilotos devem medir frotas em vez de presumir que os resultados de um único dispositivo se generalizam.

O diretório telefônico online exige internet e números previamente verificados para ambos. Isso não bloqueia o QR sem internet; após a verificação, Próximos também pode parear localmente offline.

Na camada online, o conteúdo permanece criptografado de ponta a ponta, mas os metadados de entrega, sinalização e retransmissão — identificadores, marcas de tempo, endereços IP — são processados por servidores e infraestrutura TURN.

SegurançaO Crisis Connect não substitui os serviços de emergência oficiais. Quando qualquer caminho de área ampla estiver disponível, os usuários ainda devem tentar o número de emergência local, como 112, 911 ou o equivalente nacional designado.

Cenários de Implantação

Mensagens criptografadas de ponta a ponta e chamadas de voz e vídeo com entes queridos distantes enquanto a internet estiver ativa

Comunicação familiar ou de equipe com contatos adicionados localmente por QR antes ou durante uma queda, ou por telefone verificado quando os requisitos forem atendidos

Mensagens e compartilhamento de localização offline durante viagens ou trabalhos em campo sem conectividade

Desastres como terremotos ou colapsos de infraestrutura, onde as vítimas utilizam sinais de socorro e os socorristas verificam antes de iniciar a comunicação segura

Vítimas com acesso à internet que enviam seus relatórios de socorro para painéis de resposta autorizados

Grupo de bate-papo seguro exclusivo para resposta a emergências via Wi-Fi Aware em dispositivos Android compatíveis

Coordenação e anúncios gerais na área através da rede mesh GATT pública, quando explicitamente habilitada

Chamadas de voz via links Bluetooth diretos quando o RF e o envelope de energia permitirem

Download de mapa offline, ferramentas locais de sobrevivência ou utilitárias e fluxos de trabalho de preparação para emergências em clientes móveis suportados

Sincronização opcional do Crisis Link com sistemas de backend institucionais após a recuperação da internet validada

Resultado Arquitetônico

A arquitetura móvel da Crisis Connect é intencionalmente conservadora: enquanto a internet estiver ativa, o conteúdo viaja em envelopes criptografados de ponta a ponta e os servidores permanecem cegos para ele; quando as redes falharem, o Bluetooth direto é o caminho padrão para incidentes, a confiança é estabelecida fora do sistema, os fluxos seguros são controlados por certificados e a nuvem permanece fora da rota de emergência local. O sistema é adequado para pilotos institucionais orientados por evidências ao redor da linha de lançamento do Android, enquanto uma implantação mais ampla para responder deve esperar pela validação no campo contra as portas de aceitação declaradas.

Código Aberto

Código fonte e implementação

A arquitetura do Android, a linha de lançamento pública atual e o transporte Bluetooth offline-first, juntamente com a lógica de promoção do Rescue Mode e o plano de confiança criptográfica, estão publicados abertamente para revisão e reprodutibilidade.

emirhan-duman/Crisis-Connect

AGPL-3.0Problemas

Ver repositório