Proteggere i dati dei messaggi con la crittografia end-to-end

L'Android Transport Layer, insieme all'intera connessione tra il tuo server, i backend FCM e i dispositivi client, è protetto tramite Transport Layer Security (TLS). In questo modo viene fornita una crittografia point-to-point efficace per tutti i dati in transito, proteggendoli dall'intercettazione sulla rete. Questo modello di sicurezza solido è adatto alla maggior parte delle applicazioni. Puoi trovare maggiori dettagli nella documentazione relativa all'architettura di FCM.

Uno dei limiti della crittografia point-to-point è che non è criptata per l'intero percorso in cui solo il mittente e il destinatario possono decodificare il messaggio. Per questo motivo FCM consiglia di utilizzare la crittografia end-to-end per le comunicazioni sensibili alla privacy, come i messaggi di chat o le transazioni di autenticazione. Per ottenere il massimo dalla crittografia end-to-end, questa deve essere implementata a un livello superiore, ad esempio all'interno dei server e del codice dell'app.

Aggiungere la crittografia end-to-end per i dati sensibili

Per le applicazioni che gestiscono dati particolarmente sensibili, come messaggi privati o credenziali personali, puoi aggiungere un ulteriore livello di protezione con la crittografia end-to-end (E2EE). La procedura prevede la crittografia del payload del messaggio sul server prima di inviarlo a FCM e la decrittografia all'interno dell'app sul dispositivo dell'utente. Questo funziona con i messaggi di dati FCM, poiché i payload di notifica standard vengono gestiti dal sistema operativo e non possono essere decriptati dalla tua app prima di essere visualizzati.

Tieni presente che FCM non fornisce una soluzione integrata per la crittografia end-to-end. È tua responsabilità implementare questo livello di sicurezza all'interno della tua applicazione. Esistono librerie e protocolli esterni progettati per questo scopo, come Capillary o DTLS.

Esempio concettuale

Ecco come cambia il payload FCM data quando si utilizza la crittografia end-to-end.

Before Encryption (Standard Payload):

    {
      "token": "DEVICE_REGISTRATION_TOKEN",
      "data": {
        "sender": "user123",
        "message_body": "Your 2FA code is 555-123",
        "timestamp": "1661299200"
      }
    }

Dopo la crittografia (payload E2EE):

  {
    "token": "DEVICE_REGISTRATION_TOKEN",
    "data": {
      "encrypted_payload": "aG9va2Vk...so much encrypted gibberish...ZW5jcnlwdA=="
    }
  }

Se hai implementato correttamente la crittografia end-to-end, l'applicazione client è l'unica parte in grado di decrittografare il payload criptato per rivelare il messaggio originale.

Alternativa: recupero dei contenuti direttamente dal tuo server

Se la crittografia end-to-end non è adatta alla tua app, puoi invece inviare messaggi di dati vuoti. Questi messaggi fungono da indicatore per l'app per recuperare i contenuti direttamente dai tuoi server. Ciò significa che i dati sensibili vengono trasferiti solo tra la tua app e i tuoi server, bypassando FCM per il trasferimento dei dati.

Uno svantaggio di questo metodo è il potenziale ritardo causato dalla connessione dell'app al server per recuperare i dati. Quando un'app riceve un messaggio di dati, in genere ha solo pochi secondi per visualizzare una notifica prima di essere messa in background. Il recupero dei dati dal server potrebbe non essere completato entro questo periodo. L'esito positivo del recupero dei dati dipende da fattori quali la connettività del dispositivo dell'utente.

Pertanto, valuta alternative per l'esperienza utente per le situazioni in cui il recupero dei dati potrebbe richiedere troppo tempo. Ad esempio, potresti visualizzare una notifica generica come "Hai un nuovo messaggio" e poi aggiornarla una volta recuperati i contenuti completi.