Come includere in modo sicuro chiave/firma segreta nelle app iOS/Cocoa

Question

Desidero includere una chiave segreta in un'app iOS in modo che l'app possa "provare" a un determinato server che una richiesta proviene dall'app stessa e non qualche altro sistema. So che semplicemente l'hardcoding di una chiave segreta nel codice stesso è molto vulnerabile dato che chiunque può eseguire il jailbreak del proprio telefono e collegare GDB al processo della mia app per ottenere la chiave. Esistono modi più sicuri per farlo? È possibile nascondere sufficientemente la chiave per rendere questo quasi impossibile?

Credo che questo sia un problema simile alla convalida del numero di serie. Sfortunatamente, sembra che si rompa regolarmente e facilmente. Ci sono soluzioni a questo?

Tutte le comunicazioni con il mio server verranno eseguite con HTTPS, quindi almeno gli attacchi di sniffing/man in the middle non dovrebbero costituire un problema.

Grazie, M

Answer 1

Ho paura che non sia possibile farlo. Ma per quanto ne so, Apple si assicurerà che nessun'altra app stia falsificando il segreto della tua app. Se si tratta di un telefono jailbroken, l'utente si assume la piena responsabilità e il possibile danno dovrebbe essere limitato solo ai dati dell'utente del telefono jailbroken.

Answer 2

Una risposta al solito sta attuando protocolli "tremare la mano", in cui il server invia una "sfida" e il cliente deve fornire una risposta valida.

Ciò consente una sicurezza molto maggiore rispetto a una risposta codificata, ma richiede un algoritmo intelligente (ad esempio, per evitare gli hash standard).

Answer 3

Poiché l'utente malintenzionato avrebbe il controllo completo del cliente, l'unico metodo sarebbe la sicurezza attraverso l'oscurità. È possibile implementare un modello di sfida/risposta, ma è necessario renderlo impermeabile a molti altri fattori (attacchi di riproduzione, ecc.).

This question contiene un approccio per nascondere una chiave segreta in codice binario.

Non dare per scontato che semplicemente utilizzando https non si possa avere lo sniffing dei pacchetti. Cosa succede se l'utente malintenzionato ha modificato i propri URL all'interno del file eseguibile per puntare al proprio server? Quindi possono fungere da relè.

Un modo migliore sarebbe quello di fornire una gestione dell'identità all'interno dell'app (l'utente sceglie un nome utente, la password è utente/macchina generata) e usa quelle credenziali per le chiamate di servizio.

Answer 4

Mi sono chiesto anche questo e sono venute in mente diverse soluzioni potenziali basate sulla premessa che quello che vuoi è ottenere un utente/passare una chiave segreta nel KeyChain della tua app (che è abbastanza sicuro da iOS e l'hardware) e tirarlo per l'uso al bisogno:

1. distribuire il segreto per la vostra applicazione utilizzando un iCloud ubiquità-contenitore specifico-app. questi dati dovrebbero essere esclusi dal backup sul computer locale e si presume siano trasmessi in modo sicuro utilizzando la sicurezza a livello di hardware solo alle applicazioni non jailbreak. pro: non è nella tua applicazione alla distribuzione iniziale, quindi è più difficile da scoprire, iCloud richiede un dispositivo non jailbroken, puoi aggiornare il tuo segreto e si sincronizzerà con tutte le tue app. con: non è davvero nella KeyChain sicura, il che significa che è probabile che venga annusato sul filesystem se iCloud si sincronizza e quindi il dispositivo viene jailbroken.

2. consegnare il segreto alla tua app come parte di contenuto di acquisto in-app ospitato da app-store gratuito. quando viene consegnato (in modo sicuro dall'app store, solo ai dispositivi non jailbroken) all'app, trasferirlo nel portachiavi.pro: non è nella tua applicazione alla distribuzione iniziale, quindi è più difficile da scoprire, l'app-store richiede un dispositivo non jailbroken. con: più difficile cambiare rapidamente il segreto per tutte le installazioni, anche un acquisto di app-store gratuito potrebbe richiedere l'autenticazione dell'utente, che è una UX problematica.

Una soluzione ideale sarebbe se potessimo segreti in qualche modo del bundle (un/dizionario valore chiave KeyChain) proprio in app, quando sottoponiamo per la distribuzione, l'app-store metterebbe a nudo questi e fornire in modo sicuro al Sistema operativo per l'iniezione nella KeyChain durante l'installazione, ma fuori banda dal normale pacchetto di app sincronizzato con la macchina desktop e iTunes, e non apparirebbero nei binari. Escludendo Apple aggiungendo una funzionalità del genere, penso che non ci sia una soluzione veramente solida, però.

• Aggiornamento Jun'15: Fino a quando i Sorprendentemente difetti cattivi nella sicurezza di iOS (e OS X) portachiavi sono risolti (vedi Unauthorized Cross-App Resource Access on MAC OS X and iOS) non è possibile utilizzare il Portachiavi per fissare qualsiasi cosa ragionevolmente. Non usarlo

Answer 5

Se si esegue l'hardcode della chiave all'interno dell'App, ci sono più possibilità di hackerarlo, quindi sarebbe meglio se l'App invia una richiesta al server ogni volta e riceve la chiave dal server.

Answer 6

Sono d'accordo con @Nubis sul fatto che non esiste un metodo antiproiettile al 100% per farlo.

Tuttavia, questa biblioteca sembra una soluzione pragmatica al problema:

https://github.com/UrbanApps/UAObfuscatedString

Probabilmente non sarà salvare da un attaccante molto motivati, ma non faranno la loro vita facile.