# 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](../../privacy/).

## Três caminhos de dados

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

| Função                          | Caminho dos dados                                                                | Processamento do conteúdo                                                                                            |
| ------------------------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Notificações nativas            | Caixa de e-mail → posto → serviço de envio de notificações → Apple APNs → iPhone | O posto lê o e-mail e criptografa as notificações; o iPhone verifica a assinatura, descriptografa e exibe o conteúdo |
| Leitura do conteúdo sob demanda | iPhone → seu posto → caixa de e-mail; a resposta retorna pelo mesmo caminho      | O posto processa o conteúdo e o app o exibe na sessão de leitura atual                                               |
| Dispositivos e compras          | App ↔ serviço de dispositivos e compras                                         | Registra dispositivos e verifica compras; o serviço de envio verifica a autorização e os direitos antes de enviar    |

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](backup.md) 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](connect-app.md) .

## 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

| Participante                      | Dados que pode processar para cumprir sua função                                                                                                      |
| --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| Seu posto                         | Credenciais da caixa de e-mail, mensagens em texto claro, configurações de notificação, chaves públicas de emparelhamento e registros locais de envio |
| Serviço de envio de notificações  | Identificadores do posto, dispositivo e emparelhamento; chaves públicas; tokens APNs; envelopes criptografados; horários e estados de envio           |
| Serviço de dispositivos e compras | Identidade do serviço, informações de dispositivos e sessões, compras e direitos, e metadados de diagnóstico de envio                                 |
| Apple APNs                        | Tokens push, informações de roteamento e envio, avisos genéricos e conteúdo criptografado                                                             |
| Seu iPhone                        | Chaves do dispositivo, notificações descriptografadas, histórico local e conteúdo de mensagens cuja leitura foi autorizada                            |

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](notifications.md) para campos de dados de terceiros e opções de visualização.