Stratificazione della crittografia su HTTPS [duplicato]

Potresti utilizzare HTTPS con blocco della chiave pubblica . In questo modo, solo il tuo certificato è valido per la comunicazione. Un aggressore man-in-the-middle non può più creare un certificato valido per annusare il traffico.

Il blocco dei tasti è abbastanza comune per le app mobili. Dovresti controllare se il framework HTTP che usi lo supporta.

Se la tua preoccupazione è un dispositivo jailbroken, aggiungere la crittografia sopra TLS non aggiungerebbe alcun vantaggio: un utente malintenzionato potrebbe rubare le chiavi dalla memoria o utilizzare strumenti come frida per dirottare il controllo dell'applicazione e applicare patch alle parti "cripto" per rivelarne il contenuto. Se stai utilizzando PKI su TLS, è solo uno spreco di risorse e ci sono buone possibilità che tu lo implementerai in modo errato (pensa a bloccare la chiave, a mantenere gli elenchi di revoca dei certificati, ecc.)

In altre parole, se la sicurezza del trasporto è la tua unica protezione, allora devi ridisegnare la tua applicazione. Se si dispone di una qualsiasi forma di dati sensibili archiviati sul lato client, magari codificati nell'app che, se esposti, potrebbe compromettere l'intera rete, si sta facendo male.

Esistono linee guida per iOS e Android su come memorizzare" segreti "su un telefono, oltre al solito OWASP REST security guida.

Mentre ci sono vari esempi di servizi che fanno questo genere di cose, nessuno di loro in realtà risolve il problema di un endpoint compromesso. Come dice la frase:

if the attacker compromises your device it is no longer your device

In effetti, qualsiasi cosa tu faccia è inutile una volta che l'attaccante ha il controllo di quel dispositivo, in quanto può leggere o falsificare qualsiasi certificato, chiave o frase che puoi usare su di esso.

Questa è l'area in cui i moduli hardware fidati possono fare la differenza. Se il dispositivo ha un chip o un modulo che non può essere suddiviso in (e non può, voglio dire, non in un lasso di tempo realistico dal tuo aggressore atteso) quindi qualsiasi segreto che devi usare può essere memorizzato lì. Ciò richiede comunque un'architettura che impedisca al pirata informatico di intercettare le comunicazioni sul dispositivo o di sovvertire il processo di scambio delle chiavi.

Nel tuo esempio, tuttavia, suggerirei che non è realistico aggiungere un ulteriore livello di crittografia, poiché non ti proteggerà dal modello di minaccia dichiarato. Invece, puoi disabilitare la connessione dai dispositivi rooted?

Il problema con la tua proposta è che nessuna aggiunta di livelli di crittografia / convalida PKI renderebbe il dispositivo compromesso sicuro, perché il dispositivo è compromesso.

Credo che la domanda (posta da altri) sia esattamente ciò che stai cercando di evitare: se la tua preoccupazione è qualcuno che "spoofing" un utente, quindi aggiungere un secondo fattore, e uno con la speranza di coinvolgere qualche altro dispositivo / token, sembra l'approccio più realistico.

Può essere utile verificare in che modo alcuni dei client di chat sicuri disponibili gestiscono la crittografia e la privacy: la maggior parte finisce per supporre che il dispositivo di un utente possa essere considerato affidabile (si veda ad esempio link ), e costruisci da questo fatto.

A parte l'introduzione del controllo delle asserzioni per i dispositivi utente, non c'è molto che si possa fare per proteggersi dagli utenti con dispositivi compromessi. Non è chiaro che tu debba necessariamente preoccuparti di questo: ci deve essere una sorta di demarcazione, e presumere che il dispositivo sia sicuro è molto comune.