Crittografia avanzata per la chiave pubblica codificata Base64 in Android

Per prima cosa, nota che ciò di cui hai bisogno non è la crittografia. Questo consiglio riguarda le chiavi pubbliche. Le chiavi pubbliche sono, come indica il nome, non segrete (tranne a volte per la privacy, ma quando la chiave dell'applicazione è nell'applicazione, non c'è privacy). Quello di cui hai bisogno è garantire l' integrità della chiave pubblica, ad esempio assicurarti che un'entità maligna non possa sostituirla con una chiave diversa.

L'applicazione utilizza la chiave pubblica per autenticare un ordine d'acquisto. La normale sequenza di eventi per un acquisto è:

1. L'utente contatta un server di Google e paga dei soldi per acquistare una funzione in-app.
2. Il server di Google emette una ricevuta per tale acquisto. Firma questa ricevuta con una chiave privata che non lascia mai il server.
3. La tua applicazione in esecuzione sul dispositivo mobile scarica la ricevuta.
4. La tua applicazione verifica che la ricevuta sia autentica, facendo affidamento sulla chiave pubblica in dotazione con l'applicazione.
5. Se l'acquisto è ripetibile (ad esempio consentendo di scaricare X minuti di contenuto protetto, anziché sbloccare una funzione), l'applicazione deve garantire che lo stesso scontrino non possa essere utilizzato due volte (attacco di riproduzione). Lo fa "consumando" l'acquisto.

Il problema è che l'utente può modificare il codice oi dati dell'applicazione per inserire una chiave pubblica di sua scelta al posto di quella originale. In particolare, può inserire una chiave pubblica per la quale conosce la chiave privata. Se lo fa, può generare ricevute di acquisto senza passare attraverso alcun server e la tua applicazione le accetterà come autentiche al punto 4.

Quello che devi fare per proteggere da questo attacco è rilevare qualsiasi tentativo di modificare la chiave pubblica. Non importa se il potenziale attaccante può leggere la chiave pubblica, a condizione che non possa cambiarla. Ciò significa che l'applicazione deve contenere codice che verifica che la chiave sia autentica. Ma qualunque cosa tu faccia, l'attaccante potrebbe cambiare il codice di verifica (basta capovolgere un po 'da qualche parte per cambiare if is_genuine(public)key) in if not(is_genuine(key)) ) ...

Quindi devi rendere impossibile per l'utente malintenzionato trovare il codice di verifica. Non solo: devi renderlo impossibile saltare il codice di verifica e nella parte interessante. Hai bisogno di offuscare la tua intera domanda. Tuttavia, l'offuscamento è difficile se non impossibile .

Ci sono solo due modi in cui puoi beneficiare dell'offuscamento:

• Se a nessuno interessa la tua app, forse nessuno proverà a decifrarla. (Lato negativo: non stai facendo neanche soldi.)
• Ci metti molto impegno e spero solo che rimanga per un po 'di tempo. Nota che uno sforzo significativo deve essere inserito in ogni versione: se un sacco di software viene rilasciato con le stesse tecniche di offuscamento, qualcuno troverà un modo per craccarlo e tutto quel software sarà esposto.

Per una storia di successo di offuscamento, ti consiglio di leggere la storia di Gavin Dodd sul gioco Spyro: YOTD . I punti chiave sono che ci sono voluti molti sforzi, che l'obiettivo era solo ritardare il crack per un paio di mesi, e che si basava in parte sulla psicologia degli attaccanti che passano solo un tempo limitato ad attaccare ogni partita e si fermano come non appena hanno superato il primo ostacolo.

Nella maggior parte dei casi, l'offuscamento ti costerà molto di più di quanto possa avvantaggiarti.

Quindi cosa puoi fare? Come consigliato nell'articolo: non verificare l'acquisto sul dispositivo, verificarlo su un server sotto il tuo controllo. Questo è utile solo se il risultato dell'acquisto proviene da un server. Ad esempio, se l'acquisto è per contenuti o funzionalità aggiuntivi, la ricevuta dovrebbe sbloccare il contenuto nell'account dell'utente sul server e l'app scaricherà qualsiasi contenuto che il server gli consente di avere.

Qualunque sia la crittografia che utilizzi, è ancora sul dispositivo del cliente, in modo che possano decodificarlo. Stai incontrando lo stesso problema dei sistemi DRM, per cui è possibile modificare qualsiasi che si consegna all'utente.

Se la sicurezza della tua applicazione dipende dalla segretezza della tua chiave pubblica, allora hai un difetto fondamentale nella tua architettura e devi attaccare il problema da una diversa angolazione.

Se stai solo cercando di impedire agli utenti di modificare la chiave pubblica in modo che possano utilizzare server privati personalizzati, allora il massimo che puoi fare è offuscarlo e sperare per il meglio.

@Polynomial lo ha praticamente inchiodato come al solito, ma per qualche espansione su cosa intende per obfuscate ;

Come suggerisce la documentazione di Android, vuoi rendere la chiave pubblica un po 'difficile da estrarre dal binario. In pratica hai due livelli di protezione;

1. Costruisci la chiave in fase di esecuzione utilizzando un approccio ragionevolmente complesso. XOR è buono, una sorta di iterazione è buona, anche la trasposizione e la sostituzione sono buone.
2. Offusca il meccanismo di derivazione della chiave. Con questo voglio dire utilizzare tecniche anti-debug per il tuo codice. Pochi sviluppatori vanno fino a questo punto, ma tutto ciò aiuta.