# Sécurité et chiffrement

Le push natif Mailwake chiffre les notifications sur votre avant-poste et les déchiffre sur l'iPhone couplé. Cet article décrit les clés, le flux de chiffrement et les limites des données dans Mailwake 1.0, afin que vous puissiez comprendre ce que vous contrôlez et ce qui passe par les services officiels. Le traitement et la conservation des données sont couverts par la [politique de confidentialité](../../privacy/).

## Trois chemins de données

Les notifications, la lecture du contenu des e-mails et l'identité du service utilisent des chemins distincts :

| Fonction                        | Parcours des données                                                                       | Traitement du contenu                                                                                                              |
| ------------------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| Notifications natives           | Boîte mail → avant-poste → service de transmission des notifications → Apple APNs → iPhone | L’avant-poste lit les messages et chiffre les notifications ; l’iPhone vérifie la signature, déchiffre et affiche le contenu       |
| Lecture du contenu à la demande | iPhone → votre avant-poste → boîte mail ; la réponse suit le chemin inverse                | L’avant-poste analyse le contenu et l’app l’affiche dans la session de lecture en cours                                            |
| Appareils et achats             | App ↔ service des appareils et des achats                                                 | Enregistre les appareils et vérifie les achats ; le service de transmission contrôle les autorisations et les droits avant l’envoi |

Votre avant-poste peut lire le courrier auquel il est autorisé à accéder. Le chiffrement de bout en bout couvre ici le **contenu de notification natif entre l'avant-poste et l'appareil couplé**. Le fournisseur de boîte aux lettres, l'hôte d'avant-poste et le appareil qui déchiffre restent chacun dans une limite où le texte en clair est accessible.

## Qui détient les clés

**La clé d'identité de l'avant-poste** signe le contenu. L'avant-poste génère localement une clé de signature P-256 et la chiffre avec sa clé de configuration locale. Les appareils couplés et le service de transmission des notifications reçoivent leur clé publique pour vérifier la source. L'identité reste dans le répertoire de données lors des redémarrages.

**L'appareil utilise deux clés P-256 distinctes** : une clé de signature prouve l'identité de l'appareil et le consentement au appairage, tandis qu'une clé privée d'accord de clé déchiffre les notifications. L'application crée des clés dans Secure Enclave lorsqu'elles sont disponibles et utilise des clés logicielles dans d'autres environnements d'exécution. Le trousseau partagé met les enregistrements clés à la disposition de l'application et de ses extensions, en utilisant la protection `AfterFirstUnlockThisDeviceOnly` avec la synchronisation du trousseau iCloud désactivée. L'accès par clé en arrière-plan nécessite le premier déverrouillage de l'appareil après un redémarrage.

L'avant-poste et le service de transmission des notifications stockent les clés publiques de l'appareil. L'appareil détient sa clé privée de déchiffrement ; les services officiels et les APNs ne détiennent pas cette clé privée.

L'avant-poste utilise également `secret.key` dans son répertoire de données pour chiffrer la configuration sensible, y compris les informations d'identification de la boîte aux lettres, avec AES-256-GCM. La base de données et la clé locale forment ensemble des données récupérables : [sauvegardez-les ensemble](backup.md) et protégez l'accès à l'hôte et aux sauvegardes. Une personne disposant à la fois de la base de données et de la clé locale peut déchiffrer cette configuration.

## Comment l’appairage établit la confiance

Un code QR de appairage push contient la clé publique de l'avant-poste, l'adresse et l'environnement du service de transmission des notifications, l'identifiant de appairage et un identifiant à usage unique valable cinq minutes. L'application affiche l'empreinte cryptographique de l'avant-poste à des fins de comparaison. Utilisez une invitation fiable du propriétaire de l'avant-poste et vérifiez ses informations de connexion avant de confirmer.

L'appareil signe son consentement, le liant à l'avant-poste, à la clé de chiffrement de l'appareil, aux informations d'identification à usage unique et à l'expiration. L'avant-poste vérifie cette preuve et verrouille l'identité de l'appareil et les clés publiques avant de terminer l'enregistrement auprès du service de transmission des notifications. Les notifications ultérieures utilisent cette relation confirmée pour sélectionner les clés de chiffrement et de vérification.

Une invitation de gestion peut inclure un appairage push, mais l'autorisation reste distincte : le push natif, la gestion de la configuration et la lecture du contenu des e-mails ont chacun leur propre étendue d'autorisation. Pour la configuration, voir [Connectez l'application](connect-app.md) .

## Comment une notification est chiffrée

Pour chaque opération de chiffrement, l'avant-poste génère une paire de clés éphémères P-256, un sel aléatoire de 32 octets et un nonce aléatoire de 12 octets. Il effectue ensuite les opérations suivantes :

1. Effectue un accord de clé ECDH P-256 en utilisant la clé privée éphémère et la clé publique de l’appareil cible pour obtenir un secret partagé.
2. Dérive une clé de contenu de 256 bits avec HKDF-SHA256. Le contexte de dérivation lie l'audience du service de transmission des notifications, l'ID d'appairage et l'ID d'événement.
3. Chiffre le JSON de notification avec AES-256-GCM, en utilisant le même contexte que les données authentifiées supplémentaires et en produisant un texte chiffré avec une tag d'authentification de 128 bits.
4. Signe l'enveloppe et le contexte chiffrés à l'aide de la clé de signature de l'avant-poste P-256 avec SHA-256, puis les soumet au service de transmission des notifications via HTTPS.
5. Le service de transmission des notifications vérifie la signature et le format de l'enveloppe et transmet le texte chiffré aux APNs. L'appareil vérifie d'abord la signature à l'aide de la clé publique d'avant-poste confirmée lors de l’appairage, puis dérive la clé de contenu avec sa propre clé privée, vérifie l'étiquette d'authentification et déchiffre.

L'identifiant de l'algorithme est `P256-HKDF-SHA256-A256GCM` . Les nouvelles tentatives de la même diffusion réutilisent son enveloppe stockée et son identifiant d'événement ; les nouvelles opérations de chiffrement génèrent de nouvelles clés éphémères et des valeurs aléatoires. L'extension du service de notification gère les notifications ordinaires. L'extension Widget gère les activités en direct avec code de vérification, qui contiennent également du texte chiffré signé et lient les champs d'identité et de cycle de vie de l'activité dans le contexte de chiffrement.

Les notifications chiffrées contiennent l'étiquette de la boîte aux lettres, le dossier, l'expéditeur, l'objet et l'heure de réception, avec un code de vérification facultatif et une référence au message. Le contenu complet des messages utilisent le chemin séparé ci-dessous. Si la vérification ou le déchiffrement de la signature échoue, l'appareil conserve un espace réservé sécurisé ; Le texte brut du courrier ne s'affiche qu'après une vérification réussie.

## Le contenu des messages est récupéré directement via HTTPS

L'ouverture du contenu de l'e-mail envoie une demande à l'adresse HTTPS de l'avant-poste confirmée. L'avant-poste vérifie les informations d'identification de l'appareil, l'autorisation de contenu explicite du propriétaire et l'étendue des ressources dans la référence du message signé avant de récupérer le contenu de l'e-mail et les images en ligne référencées à partir de la boîte aux lettres. La lecture du contenu des e-mails est gratuite ; L'appairage push seul n'accorde aucun accès au contenu des messages.

L'avant-poste nettoie le HTML et fournit un texte de secours lisible. L'application contrôle le chargement d'images à distance, qui peut contacter le serveur de l'expéditeur, via ses options de chargement d'images. Les pièces jointes ordinaires sont en dehors de ce flux de lecture du contenu des e-mails.

L’avant-poste traite les corps des messages en mémoire pendant la requête. Les réponses utilisent `Cache-Control: no-store` ; l’application désactive le cache HTTP et refuse les redirections. Après une lecture réussie, elle enregistre séparément le corps et l’autorisation d’images sur cet iPhone, pour une lecture hors ligne et après redémarrage. Les fichiers bénéficient de la protection iOS et sont exclus des sauvegardes. La suppression ou l’expiration d’une notification supprime aussi son corps et son autorisation d’images. Retirer un avant-poste efface ses corps enregistrés tout en conservant les résumés des notifications. Les images distantes restent temporaires et peuvent nécessiter une nouvelle connexion. Les corps arrivent directement de l’avant-poste, sans passer par les services officiels, et sont exclus des diagnostics et journaux.

## Ce que les services officiels peuvent voir

| Intervenant                               | Données traitées pour remplir son rôle                                                                                                            |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| Votre avant-poste                         | Identifiants de messagerie, messages en clair, paramètres de notification, clés publiques d’appairage et journal local des envois                 |
| Service de transmission des notifications | Identifiants de l’avant-poste, des appareils et des appairages ; clés publiques ; jetons APNs ; enveloppes chiffrées ; heures et états des envois |
| Service des appareils et des achats       | Identité de service, informations sur les appareils et sessions, achats et droits, métadonnées de diagnostic des envois                           |
| Apple APNs                                | Jetons push, informations de routage et d’envoi, affichage générique et contenu chiffré                                                           |
| Votre iPhone                              | Clés de l’appareil, notifications déchiffrées, historique local et contenu des messages dont la lecture est autorisée                             |

L'expéditeur, le sujet et le code de vérification se trouvent dans le texte chiffré de notification natif. Les intermédiaires traitant le texte chiffré peuvent toujours observer les relations de livraison, le calendrier et la taille des charges utiles. Les diagnostics de livraison opérationnelle utilisent des identifiants, des statuts, des codes d'erreur et des horodatages ; le contenu du courrier conserve la limite de chiffrement ci-dessus. Les services traitent également les informations réseau nécessaires à leurs rôles, comme décrit dans la politique de confidentialité.

## Enregistrements locaux, révocation et limites de sécurité

Les livraisons en attente et l'historique de l'administrateur sur l'avant-poste ont des règles de stockage distinctes ; l'historique local peut contenir des résumés de boîtes aux lettres et de sujets. L'application stocke l'historique des notifications déchiffrées dans son groupe d'applications local avec une protection des données des fichiers système, une conservation configurable et une action d'effacement de l'historique. Les corps des messages utilisent le cache protégé distinct décrit ci-dessus.

La dissociation arrête la livraison ultérieure via cette relation. La révocation d'un identifiant de contenu ou de gestion met fin à l'accès correspondant. Le contenu déjà livré et déchiffré doit être effacé sur l'appareil ; la révocation ne peut pas rappeler le contenu que quelqu'un a déjà vu.

Cette conception dépend de la sécurité de l'hôte de l'avant-poste, de l'invitation d'appairage et de l'appareil. Il protège le contenu des notifications en transit tandis qu'un avant-poste compromis ou un appareil déverrouillé peut exposer du texte en clair. Le protocole utilise une clé privée à long terme de l’appareil pour l’accord de clé : si cette clé est compromise, une personne détenant un texte chiffré historique peut déchiffrer les anciennes notifications. Cette conception ne fait donc aucune garantie de confidentialité persistante contre la compromission de la clé privée à long terme du destinataire.
Les canaux Bark, Pushover et webhook envoient leurs charges utiles respectives au service que vous configurez. Le protocole de chiffrement natif ci-dessus s'applique au canal natif Mailwake. Voir [Canaux de notification](notifications.md) pour les champs de données tiers et les options d'aperçu.