Salut, Habr !
Aujourd'hui, je vais vous parler de ce sur quoi mes collègues et moi travaillons depuis plusieurs mois : les notifications push pour les messageries mobiles. Comme je l'ai déjà mentionné, notre application met l'accent sur la sécurité. Nous avons donc examiné s'il existe des « points faibles » dans les notifications push, et si oui, comment nous pouvons les atténuer afin d'ajouter cette option utile à notre service.
Je publie la traduction de notre avec quelques ajouts de ma part. Ce document présente les conclusions de notre « enquête » et explique comment nous avons résolu le problème.
Explorons la matière
Dans le modèle classique, les notifications push rendent les messageries vulnérables aux attaques MITM (Man-in-the-middle, « Homme du milieu »). Par exemple, Google, Microsoft et l'ancienne version d'iMessage envoient des clés de chiffrement aux serveurs d'Apple — l'authentification des utilisateurs et le déchiffrement de l'en-tête du message (ou de son contenu) se font sur le serveur.
Il y a donc un risque de lire la correspondance en accédant au serveur des notifications push. Cela signifie que tout chiffrement de la correspondance est inutile : les notifications push laissent toujours la possibilité d'être lues par des tiers. Les auteurs de l'article ont discuté en détail de cette possibilité dans sur Xaker.ru, dédié aux méthodes de chiffrement des messages.
Si vous pensez que les serveurs d'Apple et de Google ne permettront jamais une fuite des clés de chiffrement des utilisateurs, réfléchissez au fait que leurs employés y ont accès. Et les employés, ce sont des gens.
Malgré toutes les vulnérabilités des notifications push, de nombreux messageries « sûres », y compris Signal et Telegram, les utilisent. Sinon, les utilisateurs devraient « manuellement » surveiller les nouveaux messages en se connectant constamment à l'application. Ce qui est plutôt peu pratique, et les messageries concurrentes en tireront un avantage.
Paranoïa et bon sens
Dans notre projet, nous avons abordé cette question de manière approfondie il y a plusieurs mois. Nous devions créer l'option de notifications push pour rester compétitifs. Mais nous devions également éviter de créer une faille de sécurité, car toute fuite de données nuirait à la confiance dans le projet.
Cependant, nous avons déjà un avantage important : notre messager est décentralisé (les données sont stockées dans la blockchain), et les employés n'ont pas accès aux comptes. Les clés de chiffrement n'appartiennent qu'aux utilisateurs, tandis que les clés publiques des interlocuteurs sont disponibles dans la blockchain pour se protéger contre les attaques MITM.
Dans la première version des notifications push, nous avons décidé de prendre un maximum de précautions et de ne pas transmettre du tout le texte du message. Le service push recevait de la part du nœud non pas le texte du message, mais seulement un signal indiquant qu'il avait été reçu. Par conséquent, l'utilisateur voyait une notification « Nouveau message reçu ». Il n'était possible de le lire que dans le messager.
.
Après cela, nous avons découvert que la dernière version des notifications d'Apple comportait de nouveaux éléments de protection. Ils UNNotificationServiceExtension, qui permet aux développeurs d'envoyer des données de notification entièrement chiffrées via APNS. Ensuite, l'application sur l'appareil de l'utilisateur final effectue le déchiffrement (ou charge des données supplémentaires) et affiche la notification. C'est sur cette base que nous avons élaboré la deuxième version des notifications push.
Nous avons maintenant développé une deuxième version des notifications push pour iOS, qui permet d'afficher le texte du message sans compromettre la sécurité. Dans la nouvelle concept, la logique est la suivante :
- Le service push envoie une notification avec le numéro de transaction (un message chiffré peut être très volumineux et la taille des notifications est fortement limitée)
- L'appareil, à la réception de la notification, lance notre NotificationServiceExtension — une micro-application qui demande au nœud la transaction par ID, déchiffre avec la phrase de passe sauvegardée, et renvoie un nouveau notification au système. La phrase de passe est stockée dans un coffre-fort sécurisé.
- Le système affiche une notification avec le message déchiffré ou une traduction.
- Les clés ne sortent nulle part, tout comme le message en texte clair. Le service de push n'a pas la possibilité de déchiffrer le message.
Cette version a été adoptée comme fonctionnelle et a été implémentée dans la dernière mise à jour de l'application pour iOS.
Ceux qui s'intéressent à l'aspect technique peuvent consulter le code source : .
Source : habr.com
