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 robusto è adatto alla stragrande maggioranza delle applicazioni. Puoi trovare maggiori dettagli nella documentazione sull'architettura di FCM.

Uno dei limiti della crittografia point-to-point è che non viene 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 sfruttare al meglio la crittografia end-to-end, è necessario implementarla 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. Questa operazione funziona con FCM messaggi di dati, poiché i payload di notifica standard vengono gestiti dal sistema operativo e non possono essere decriptati dall'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 dell'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 E2EE.

Prima della crittografia (payload standard):

    {
      "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 e2e, l'applicazione client è l'unica parte in grado di decriptare il payload criptato per rivelare il messaggio originale.

Alternativa: recuperare i contenuti direttamente dal server

Se la crittografia end-to-end non è adatta alla tua app, puoi invece inviare messaggi di dati vuoti. Questi messaggi fungono da segnale per l'app per recuperare i contenuti direttamente dai tuoi server. Ciò significa che i dati sensibili vengono trasferiti solo tra l'app e i 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 questa finestra. Il successo di questo recupero dei dati dipende da fattori quali la connettività del dispositivo dell'utente.

Pertanto, valuta le 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.