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

The 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, tutti i dati in transito vengono protetti con una crittografia point-to-point , che impedisce l'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 applicata all'intero percorso, ma solo al mittente e al destinatario, che 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 procedura funziona con i FCM messaggi di dati, in quanto i payload di notifica standard vengono gestiti dal sistema operativo e non possono essere decrittografati 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 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 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 end-to-end, l'applicazione client è l'unica parte in grado di decrittografare 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 trasportati 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 recuperato l'intero contenuto.