Segurança e criptografia

O push nativo do Mailwake criptografa notificações em seu posto e as descriptografa no iPhone emparelhado. Este artigo descreve as chaves, o fluxo de criptografia e os limites de dados no Mailwake 1.0, para que você possa entender o que você controla e o que passa pelos serviços oficiais. O processamento e a retenção de dados são cobertos pela política de privacidade.

Três caminhos de dados

Notificações, leitura de conteúdo de e-mail e identidade de serviço usam caminhos separados:

Seu posto pode ler o correio que está autorizado a acessar. A criptografia ponta a ponta aqui cobre conteúdo de notificação nativo entre o posto e o dispositivo emparelhado. O provedor de caixa de correio, o servidor do posto e o dispositivo de descriptografia permanecem dentro de um limite onde o texto simples é acessível.

Quem detém as chaves

A chave de identidade do posto assina o conteúdo. O posto gera uma chave de assinatura P-256 localmente e a criptografa com sua chave de configuração local. Os dispositivos emparelhados e o serviço de envio de notificações recebem sua chave pública para verificar a origem. A identidade permanece no diretório de dados durante as reinicializações.

O dispositivo usa duas chaves P-256 separadas: uma chave de assinatura comprova a identidade do dispositivo e o consentimento de emparelhamento, enquanto uma chave privada de acordo de chave descriptografa as notificações. O aplicativo cria chaves no Secure Enclave quando disponível e usa chaves de software em outros ambientes de execução. As Chaves Compartilhadas disponibilizam registros de chaves para o App e suas extensões, usando a proteção AfterFirstUnlockThisDeviceOnly com a sincronização das Chaves do iCloud desabilitada. O acesso à chave em segundo plano requer o primeiro desbloqueio do dispositivo após a reinicialização.

O posto e o serviço de envio de notificações armazenam chaves públicas do dispositivo. O dispositivo contém sua chave privada de descriptografia; serviços oficiais e APNs não possuem essa chave privada.

O posto também usa secret.key em seu diretório de dados para criptografar configurações confidenciais, incluindo credenciais de caixa de correio, com AES-256-GCM. O banco de dados e a chave local juntos formam dados recuperáveis: faça backup de ambos e proteja o acesso ao host e aos backups. Alguém com o banco de dados e a chave local pode descriptografar esta configuração.

Como o emparelhamento estabelece confiança

Um código QR de emparelhamento push carrega a chave pública do posto, o endereço e ambiente do serviço de envio de notificações, o identificador de emparelhamento e uma credencial de uso único válida por cinco minutos. O aplicativo mostra a impressão digital criptográfica do posto para comparação. Use um convite confiável do proprietário do posto e verifique as informações de conexão antes de confirmar.

O dispositivo assina seu consentimento, vinculando-o ao posto, chave de criptografia do dispositivo, credencial única e validade. O posto verifica essa prova e bloqueia a identidade do dispositivo e as chaves públicas antes de concluir o registro no serviço de envio de notificações. Notificações posteriores usam esse relacionamento confirmado para selecionar chaves de criptografia e verificação.

Um convite de gerenciamento pode incluir emparelhamento push, mas a autorização permanece separada: push nativo, gerenciamento de configuração e leitura de conteúdo de e-mail têm seu próprio escopo de permissão. Para configuração, consulte Conecte o aplicativo .

Como uma notificação é criptografada

Para cada operação de criptografia, o posto gera um par de chaves P-256 efêmero, um salt aleatório de 32 bytes e um nonce aleatório de 12 bytes. Então:

1. Executa o acordo de chave ECDH P-256 usando a chave privada efêmera e a chave pública do dispositivo de destino para obter um segredo compartilhado.
2. Deriva uma chave de conteúdo de 256 bits com HKDF-SHA256. O contexto de derivação vincula o público do serviço de envio de notificações, o ID de emparelhamento e o ID do evento.
3. Criptografa JSON de notificação com AES-256-GCM, usando o mesmo contexto que dados autenticados adicionais e produzindo texto cifrado com uma etiqueta de autenticação de 128 bits.
4. Assina o envelope criptografado e o contexto usando a chave de assinatura P-256 do posto com SHA-256 e, em seguida, envia-o ao serviço de envio de notificações por HTTPS.
5. O serviço de envio de notificações verifica a assinatura e o formato do envelope e transmite o texto cifrado para APNs. O dispositivo primeiro verifica a assinatura usando a chave pública do posto confirmada durante o emparelhamento, depois deriva a chave de conteúdo com sua própria chave privada, verifica a etiqueta de autenticação e descriptografa.

O identificador do algoritmo é P256-HKDF-SHA256-A256GCM . Novas tentativas da mesma entrega reutilizam seu envelope armazenado e identificador de evento; novas operações de criptografia geram novas chaves efêmeras e valores aleatórios. A extensão do serviço de notificação lida com notificações comuns. A extensão Widget lida com atividades ao vivo com código de verificação, que também carregam texto cifrado assinado e vinculam campos de identidade e ciclo de vida da atividade ao contexto de criptografia.

As notificações criptografadas contêm o rótulo da caixa de correio, pasta, remetente, assunto e hora de recebimento, com um código de verificação opcional e referência de mensagem. O conteúdo completo das mensagens usa o caminho separado abaixo. Se a verificação ou descriptografia da assinatura falhar, o dispositivo retém um espaço reservado seguro; o texto simples do email é exibido somente após a verificação bem-sucedida.

O conteúdo das mensagens é obtido diretamente por HTTPS

A abertura do conteúdo do e-mail envia uma solicitação para o endereço HTTPS do posto confirmado. O posto verifica a credencial do dispositivo, a permissão de conteúdo explícita do proprietário e o escopo do recurso na referência da mensagem assinada antes de buscar o conteúdo do e-mail e as imagens embutidas referenciadas na caixa de correio. A leitura do conteúdo do e-mail é gratuita; o emparelhamento push por si só não concede acesso ao conteúdo da mensagem.

O posto limpa HTML e fornece um substituto de texto legível. O App controla o carregamento remoto de imagens, que pode entrar em contato com o servidor do remetente, por meio de suas opções de carregamento de imagens. Anexos comuns estão fora deste fluxo de leitura de conteúdo de e-mail.

O posto processa os corpos das mensagens na memória da solicitação. As respostas usam Cache-Control: no-store; o aplicativo desativa o cache HTTP e rejeita redirecionamentos. Após uma leitura bem-sucedida, salva separadamente o corpo e a permissão de imagens de cada mensagem neste iPhone para leitura offline, inclusive após reiniciar o aplicativo. Os arquivos usam a proteção de arquivos do iOS e são excluídos dos backups. A exclusão ou expiração de uma notificação remove seu corpo salvo e sua permissão de imagens. Remover um posto também apaga seus corpos salvos, preservando os resumos das notificações. Imagens remotas são temporárias e podem exigir outra conexão. Os corpos chegam diretamente do posto ao aplicativo, sem passar pelos serviços oficiais, e ficam fora dos diagnósticos e logs.

O que os serviços oficiais podem ver

O remetente, o assunto e o código de verificação estão dentro do texto cifrado de notificação nativo. Os intermediários que manipulam o texto cifrado ainda podem observar as relações de entrega, o tempo e os tamanhos da carga útil. Os diagnósticos de entrega operacional utilizam identificadores, status, códigos de erro e carimbos de data/hora; o conteúdo do email mantém o limite de criptografia acima. Os serviços também processam informações de rede necessárias para suas funções, conforme descrito na política de privacidade.

Registros locais, revogação e limites de segurança

As entregas pendentes e o histórico do administrador no posto têm regras de armazenamento separadas; o histórico local pode conter resumos de caixas de correio e assuntos. O aplicativo armazena o histórico de notificação descriptografado em seu grupo de aplicativos local com proteção de dados de arquivos do sistema, retenção configurável e uma ação de limpeza do histórico. Os corpos das mensagens usam o cache protegido separado descrito acima.

O desemparelhamento interrompe a entrega adicional por meio desse relacionamento. A revogação de uma credencial de conteúdo ou de gerenciamento encerra o acesso correspondente. O conteúdo já entregue e descriptografado deverá ser apagado no dispositivo; a revogação não pode recuperar o conteúdo que alguém já viu.

Este design depende da segurança do host do posto, do convite de emparelhamento e do dispositivo. Ele protege o conteúdo da notificação em trânsito, enquanto um posto comprometido ou um dispositivo desbloqueado pode expor texto simples. O protocolo usa uma chave privada de acordo de chave de dispositivo de longa duração: se essa chave for comprometida, alguém que possua texto cifrado histórico poderá descriptografar notificações antigas. Este projeto, portanto, não faz nenhuma reivindicação de sigilo futuro contra o comprometimento da chave privada de longo prazo do destinatário.

Canais Bark, Pushover e webhook enviam suas respectivas cargas para o serviço que você configura. O protocolo de criptografia nativo acima se aplica ao canal nativo Mailwake. Consulte Canais de notificação para campos de dados de terceiros e opções de visualização.

Markdown · AGPL-3.0-only · Colaboradores do Mailwake