La couche de transport Android, ainsi que l'ensemble de la connexion entre votre serveur, les backends FCM et les appareils clients, sont sécurisés à l'aide du protocole TLS (Transport Layer Security). Cela fournit un chiffrement de bout en bout fort pour toutes les données en transit, ce qui les protège contre toute interception sur le réseau. Ce modèle de sécurité robuste convient à la grande majorité des applications. Pour en savoir plus, consultez la documentation sur l'architecture FCM.
L'une des limites du chiffrement de point à point est qu'il n'est pas chiffré sur l'ensemble de son chemin, où seuls l'expéditeur et le destinataire peuvent décoder le message. C'est pourquoi FCM recommande d'utiliser le chiffrement de bout en bout pour les communications sensibles en termes de confidentialité, comme les messages de chat ou les transactions d'authentification. Pour tirer le meilleur parti du chiffrement de bout en bout, il doit être implémenté à un niveau supérieur, par exemple dans le code de vos serveurs et de votre application.
Ajouter le chiffrement de bout en bout pour les données sensibles
Pour les applications qui traitent des données particulièrement sensibles, comme les messages privés ou les identifiants personnels, vous pouvez ajouter une couche de protection supplémentaire avec le chiffrement de bout en bout. Le processus consiste à chiffrer la charge utile du message sur votre serveur avant de l'envoyer à FCM, puis à la déchiffrer dans votre application sur l'appareil de l'utilisateur. Cela fonctionne avec les messages de données FCM, car les charges utiles de notification standards sont gérées par le système d'exploitation et ne peuvent pas être déchiffrées par votre application avant d'être affichées.
Notez que FCM ne fournit pas de solution intégrée pour le chiffrement de bout en bout. Il vous incombe d'implémenter cette couche de sécurité dans votre application. Il existe des bibliothèques et des protocoles externes conçus à cet effet, tels que Capillary ou DTLS.
Exemple conceptuel
Voici comment la charge utile data change lorsque vous utilisez le chiffrement de bout en bout.FCM
Avant le chiffrement (charge utile standard) :
{
"token": "DEVICE_REGISTRATION_TOKEN",
"data": {
"sender": "user123",
"message_body": "Your 2FA code is 555-123",
"timestamp": "1661299200"
}
}
Après chiffrement (charge utile E2EE) :
{
"token": "DEVICE_REGISTRATION_TOKEN",
"data": {
"encrypted_payload": "aG9va2Vk...so much encrypted gibberish...ZW5jcnlwdA=="
}
}
Si vous avez correctement implémenté le chiffrement de bout en bout, l'application cliente est la seule partie capable de déchiffrer la charge utile chiffrée pour révéler le message d'origine.
Alternative : Récupérer du contenu directement depuis votre serveur
Si le chiffrement de bout en bout ne convient pas à votre application, vous pouvez envoyer des messages de données vides. Ces messages servent de signal pour que l'application récupère le contenu directement depuis vos serveurs. Cela signifie que les données sensibles ne sont transférées qu'entre votre application et vos serveurs, en contournant FCM pour le transfert de données.
L'inconvénient de cette méthode est le retard potentiel causé par la connexion de l'application à votre serveur pour récupérer les données. Lorsqu'une application reçoit un message de données, elle ne dispose généralement que de quelques secondes pour afficher une notification avant d'être mise en arrière-plan. Il est possible que la récupération des données depuis votre serveur ne soit pas terminée dans ce délai. Le succès de cette récupération de données dépend de facteurs tels que la connectivité de l'appareil de l'utilisateur.
Par conséquent, envisagez d'autres alternatives pour l'expérience utilisateur dans les situations où la récupération des données peut prendre trop de temps. Par exemple, vous pouvez afficher une notification générique telle que "Vous avez un nouveau message", puis la mettre à jour une fois le contenu complet récupéré.